【読者メモ】Javaの基礎の基礎

Javaを改めて勉強しようと

Javaエンジニア養成読本』

を読んでみて、意外と抜けてたところがあったのでおさらい

 

・クラス名はキャメルケースで書くのが一般的

・staticメソッドインスタンスではなくクラスに関連付けられたメソッドなので、インスタンスとは無関係になる

・staticメソッドからは他のインスタンスメソッドを呼べない

・final修飾子のフィールドはフィールドの宣言時、コンストラクタ、イニシャライザのいずれかで代入

・他のコンストラクタを呼び出せるのはコンストラクタのみでコンストラクタの先頭行で一度のみ

コンストラクタを一つも定義しないとディフォルトコンストラクタが生成されるが、一つでも定義すると生成されなくなる

・ディフォルトコンストラクタスーパークラスの引数を持たないコンストラクタを呼び出すだけ

コンストラクタは必ずスーパークラスコンストラクタを呼び出す

スーパークラスに引数を持たないコンストラクタがない場合はsuperを使って明示的に呼び出す

・フィールドは必ず値を持つ。

・初期化を省略した場合は型により、0、false、nullのいずれかが設定される

・意味のある値はstatic finalフィールドで名前付き定数を宣言すべき

・ユーティリティクラスはコンストラクタをstaticにしてインスタンスを生成させない

・特定のインスタンスを戻り値にするstaticファクトリメソッドインスタンスの生成コストが抑えられる

・変化するstaticフィールドは1ユーザ1スレッドでもないと正しく動作しない

・アクセス修飾子はできるだけ絞る

・どこからでもアクセスできるということは結果動作を正しく把握できなくなるということ

・アクセス修飾子は4段階、private、何も書かない、protected、public

・privateはクラス内からのみアクセス可、何も書かないのは同じパッケージからのみアクセス可、protectedは継承したクラスからもアクセス可、publicは無制限にアクセス可

・クラスの仲間は抽象クラス、インターフェース、enumアノテーション

・抽象クラスはabstract修飾子をつける

・抽象クラスはインスタンスを生成できない

・抽象クラスを継承した具象クラスでインスタンスを生成する

・抽象メソッドは処理をもたず、継承したクラスで実装する

インターフェイスは抽象メソッドと名前付き定数のみ定義できる

インターフェイスのフィールドはpublic static final、インターフェイスメソッドはpublic abstractが暗黙で付与される

インターフェイスを実装したクラスはインターフェイスの型で扱えるようになる

インターフェイスメソッドを追加する場合はdefault修飾子をつけると実装クラスへの影響を抑えられる

enumクラスは列挙型と呼ばれる特別なクラス※要勉強

enumは列挙した数のインスタンスを生成する

アノテーションはクラスやメンバにメタ情報を付与する @Overrideなど

・ネストしたクラスには基本的にstatic修飾子を付与する。付与しないとインナークラスになる※要勉強

・ネストしたクラスにはstaticなネストしたクラス、インナークラス、ローカルインナークラス、匿名クラスの4種類がある

・オブジェクトは可能であればイミュータブルにしたほうがソースの可読性が上がる

・オーバーライドには、シグニチャは変更できない、アクセス修飾子は元のアクセス修飾子より緩くないといけない、戻り値は元の型かそのサブクラスでないといけない、throws節は元の型かそのサブクラスでないといけない、元のメソッドがfinalだとオーバーライドできないという制約げある

・オーバーライドするときは@Overrideを付与するのが望ましい

・abstractでないメソッドをオーバーライドするときは、オーバーライドされる想定かどうか、メソッドの目的が同じか確認する

複数コンストラクタを持つ場合はチェーンしたほうが可読性が上がる

コンストラクタからインスタンスメソッドを使用するのはあまり好ましくない

インスタンス構築の処理が複雑な場合、staticファクトリメソッドやビルダーなどインスタンス生成専用のクラスを検討する


そもそもちゃんと理解してなかったところと、完全に忘れていたところがかなりあったorz

 

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

 
 

【ラーメン】大好きなラーメンBEST3と思ったけど、やっぱりBEST4

順番はつけられませんが、

 

◆麺処 ほん田◆

http://s.tabelog.com/tokyo/A1323/A132304/13047541/

f:id:munqu:20160323011401j:plain

手揉みのちぢれ麺がおすすめです

近辺に系列店もありますが、是非本店へ

 

◆うさぎ◆

http://s.tabelog.com/tokyo/A1303/A130301/13041115/

f:id:munqu:20160323011904j:plain

最低でも二回行って、あっさり味のしょうゆと電気が走るよるな担々麺両方食べてください

 

◆山頭火◆

http://s.tabelog.com/tokyo/A1303/A130301/13003492/

f:id:munqu:20160323012546j:plain

最近は担々麺とかサンマーメンとかいろいろメニュー増えてますが最終的には塩に落ち着きます

 

AFURI

http://s.tabelog.com/tokyo/A1303/A130302/13005500/

f:id:munqu:20160323013029j:plain

見るからに美味い、間違いない一杯です

 

以上、かなりベタですみません

 

一年にせいぜい50〜100杯のライトユーザですが、なんだかんだで有名店は間違いないです

 

 

 

 

 

 

 

 

【日記】クラウド初心者がAWSさわってみたのでメモ

f:id:munqu:20160321160036j:plain

自宅PC windows7 から試しに...


1.まず始めにアカウント登録

- クレジットカード番号が必要!

設定をミスらなければ無料

- 電話番号入力欄がある

海外の知らない番号から急にかかってくるのでびっくりする

- 落ち着いてやれば特に難しいことなし


2.ドットインストールのAWS入門を真似してサービスを立ち上げてみる

http://dotinstall.com/lessons/basic_aws

- やるのはEC2、RDS、S3 

EC2はWEBサーバ

RDSはDBサーバ

S3はストレージサーバ

のイメージ?

- 引っかかった点

・そもそもAWSが授業動画作成時よりだいぶ使いやすくなっている。配置等だいぶ変わっているが、どこかにあるので探す

SSHのコマンドを使うので、windowsからの接続の場合ツールを入れないと動かない

・動画だとvimでさらっとHTMLファイルをAWSサーバ上に作ってたけど、慣れていなかったのでちょっと苦戦


3.今後

- そもそも、AWS上にドキュメントやトレーニングメニューが豊富にあるので、お金をかけないでかなり学べる、ただし資格みたいを取ろうとすると高額な費用がかかる

- 基本最初のお試しは無料だが、クレジットカード番号を入れているので間違って有料オプションつけないように気をつける

- 他のクラウドサービスも入門サイトがたくさんあるので、試しにやってみる







【学習メモ】schoo CTOの履歴書 BASE 藤川真一(えふしん)

f:id:munqu:20160321153341p:plain


CTOの履歴書 BASE 藤川真一

http://schoo.jp/class/1643/room


エンジニアとして


・今は無料で学ぶチャンスがたくさんある

   ライバルも同じ


・自分への投資を惜しまない


・年齢を重ねてからのジョブチェンジ

    いかに期待してもらうアピールができるか


・専門書を読むなら一冊で満足しない

    興味をもった分野の本は何冊も読んで深入り


・やりたい言語技術がある

    無料で学べるので、仕事外で実績を作っておく








【読者メモ】ゼロ秒思考 頭がよくなる世界一シンプルなトレーニング 赤羽雄二

いろいろ書いてありますが、結局はここの内容が全て

「メモ書き」は、1ページを1分以内、毎日10ページ書く。時間はわずか10分だ。費用はかからず、頭や感情の整理に即効性がある。右記の営業リーダーのように、行動上の課題を解決し、スタイルまで変更することができる。 メモ書きを3週間から1ヶ月続けると、頭にどんどん言葉が浮かぶようになる。メモに書くよりも早く、言葉が湧いてくる。1ヶ月前にはもやもやとしていたものが、言葉が明確に浮かび、アイデアが続々と出てくるようになる。頭の速さに手の動きがついていけず、もどかしく思いながらアウトプットし続けることになる。 さらに数ヶ月続けると、瞬間的に全体像が見えるようになり、「ゼロ秒思考」に近づいていく。ものによっては、瞬間的に問題点が見え、課題が整理でき、答えが見えてくる。この変化には、性別、年齢、経験を問わない  


サンプルはこんな感じです。

f:id:munqu:20160316233555p:plain



ゼロ秒思考  頭がよくなる世界一シンプルなトレーニング

ゼロ秒思考 頭がよくなる世界一シンプルなトレーニング

【学習メモ】schoo これからが超面白い「業務系IT」~エンジニアがすごい仕事をするチャンスと技術~ 漆原 茂 先生

ウルシステムズ x DODA

業務系SEが熱い 市場規模は○兆円


f:id:munqu:20160315224347p:plain


業務知識とITスキルどっちを伸ばしていくべき

1人で両方を極めるのは難しい

両方大事だから両方伸ばしていきつつ、

どっちかが物凄く強い2人が組めばいい


■開発手法の選択

要件が決まっているならウォーターフォール

業務から決めていくならアジャイル


■どこで知識を習得すればいいの?

業務知識や技術は意外と世の中に広まっていない

人に異存している、人の頭の中にある

世の中に広まるのは一般的で無難なものだけ

詳しい人にコンタクトを積極的にとって、教えてもらうのが一番、遠慮物怖じしたら駄目


■今後のキャリアアップ

メンバー → リーダー → マネージャー

だけがパスじゃない

キャリアは今後細分化していく

自分の武器 一芸に秀でていればokなことが多い

ただし一つの技術で勝負は武器として弱い

何かと何かの組み合わせ ハイブリッドで勝負








【学習メモ】いまさらだけどDevOpsってなに?

@IT総力特集「DevOpsで変わる情シスの未来」

f:id:munqu:20160316002922p:plain

http://ids.itmedia.jp/dl/atmarkit_ebook1_devops.pdf?bpc=f087204a1b7ff61e6f4175541ce159f382538987ea2b867aca1fa482e051e3a1

 

 

内野宏信,@ IT 

 「DevOps」という言葉が注目を集めている。一言でいえば「開発部門と運用部門が密接に連携し IT サービ スのリリースサイクルを速める」といった概念だ。

 

原田美穂,@ IT 

 DevOps の手法を考える際、ツールや環境整備に目が行きがちだが、最も重要なのは、チー ムコミュニケーションとチームの目的の持ち方である。

  

DeNAシステム本部 茂岩祐樹氏 

 「DevOps といっても、スピーディにリリースしたい開発部門と、安定運用が求められる運用部門という相反す るミッションがある以上、当然、コンフリクトが生じるわけです。 そこでお互いの利害関係だけを見て両部門の距 離を広げてしまうのか、それとも、エンドユーザーに楽しんでもらう、会社の収益を上げるといった共通のゴール を見据えて、コンフリクト解消に向けて建設的な議論を行うのか、というところが DevOps 実践の分かれ道だと 思いますね。 

  

平鍋健児氏

 ここであらためて DevOps の定義を振り返れば、その解釈にもよりますが、開発を行う「作る人」、運用部門 である「提供する人」たちが対話を行い、皆で制約を解消して連携・協働しようという概念が、すなわち DevOps ですよね。

 まずは対話の場を作り、「なぜ」このシステムが必要なのか、「なぜ」この運用管理体制が必要なの か と い っ た よ う に 、「 な ぜ 」 の 部 分 を 共 有 す る こ と か ら 始 め る と 効 果 的 か と 思 い ま す 。 ア ジ ャ イ ル を 核 に 持 つ DevOps にしても、「なぜ DevOps を実践する必要があるのか」「なぜ、このシステムはこのように開発・運用 する必要があるのか」「なぜこうしたシステムを作ると顧客はもっと喜ぶのか」といったように考えて意見を交わ す。  

  

グロースエクスパートナーズ 鈴木雄介

 アジャイルや DevOps を「開発プロセスの話」とか「運用のツールの自動化の話」といったように解釈せず、 企画、開発、運用、フィードバックという一連のサイクル加速へのビジネスニーズがある、という背景に目を向け、 そのために DevOps やアジャイルという手法が大事だと考えることが大切です。手法ばかりを見て矮小化して捉 えてしまうことなく、トレンドの裏側にある本質的なことは何かを見据えることで、これらの言葉をあらためて理解 できるのではないでしょうか。

  

@niftyクラウド本部クラウド事業部 高野祥幸氏 

 「クラウドが普及し、インフラがプログラマブルになった時点で、開発と運用を明確に切り分ける必要はなくなっ たと感じています。DevOps という言葉や形にとらわれずに、トライアンドエラーを繰り返しながら、自社のビジ ネスに最も適した仕組みを模索していくことが最も大切だと思います」 

 

共通の認識としては

・開発サイクルを早める

・開発と運用の密な連携が必要

・DevOpsはあくまで選択肢の1つ

ツールとしてよりも思想として捉えている

.・コミュニケーションがとにかく重要