なんなのこれ。
なんで一文字しか違わんの?
定義でURLを持っているんだが、httpとhttpsを書き間違えて、かなり迷った。。。
これで半日使ってたと思うと、アホらしくてしょうがない。
なんなのこれ。
なんで一文字しか違わんの?
定義でURLを持っているんだが、httpとhttpsを書き間違えて、かなり迷った。。。
これで半日使ってたと思うと、アホらしくてしょうがない。
下記の記事を見て、自分なりにまとめとメモ。
なんというか、自分も釣られる側な気がして、考えが足りてなかったなと反省の念も込めてる。
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
下記サイトから引用
個別に開発された小さなサービスを組み合わせて、一つのサービスを提供するというものです。
マイクロサービスとは何か? デジタル変革の時代を生き残るための、テクノロジー入門 - Customer Success
マイクロサービスが全知全能の銀の弾丸ではない。
正と負、どちらの効果も持っており、状況次第では負の側面が多く出ることもある。
サイト内で言っていた前提条件
- ラピッドプロビジョニング
- ベーシックモニタリング
- ラピッドデプロイメント
上記条件をすべて満たしていたとしても、本当に負の側面がないか考慮する必要がある。
処理を分散することの問題は、マイクロサービスにも存在しうるので、目をそむけてはいけない。
スケールアップ・ダウンに耐えられる人材がいるかどうか。
それも一人だけでなく、複数人が各チームに散らばっていること。
パフォーマンス計測手法が確立しているか?
確立してない場合、マイクロサービスで分断することによって、どこの何が原因なのか分からなくなるだけ。
迅速なデプロイ方法が確率されているか?
すべて手動の場合、マイクロサービスで分断されたサービスをすべて手作業でした場合、事故る確率は高い。
存在している問題点から目を背けていたかもしれない。
まだ、本格的にマイクロサービスを適用している現場に言ったことがないから、夢見てたかもしれないな。
結構、バズワードって魅力的に見えるから、飛びつきたくはなるけど、用心しなければいけない。
新手の詐欺かもしれない心持ちで、検討する必要があるなと思う。
Java9のリリースが迫っているのと、ITproの記事見て試したくなったから。
あとは、Typescriptで非同期の処理を書くことが非常に多いので、Javaでもやりたくなった。
非同期処理を実現するための仕様。
非同期処理を採用しているライブラリとして、RxJava/Akka Streamsが有名。
データの流れに着目したプログラミングスタイルで、Publish-Subscribeモデルの実装ができる。
※Publish/Subscribeは、Observerパターンの発展系みたいなもんだという認識でいる。
非同期にしなければいけないってものでもないが、データを作る側と使う側が疎結合になるので、非同期処理に移行しやすくなる。
java.util.stream.Streamインタフェースとは別ものってことには、要注意。
このフローは、RxJavaも同じ。
※Akka Streamsは知らない。。。
そして、定義されているインタフェースは、下記の通り。
とりあえずITproの奴を真似して作った。
import java.util.concurrent.Flow.Subscriber; import java.util.concurrent.Flow.Subscription; public class SampleSubscriber<T> implements Subscriber<T> { private Subscription subscription; private final String name; public SampleSubscriber(String name) { this.name = name; } @Override public void onComplete() { System.out.println(name + ": " + Thread.currentThread().getName() + ": Complete."); } @Override public void onError(Throwable arg0) { } @Override public void onNext(T item) { // 配布されたデータを出力する System.out.println(name + ": " + Thread.currentThread().getName() + ": " + item); // データの要求 subscription.request(1); } @Override public void onSubscribe(Subscription subscription) { this.subscription = subscription; subscription.request(1); } }
import java.util.concurrent.Flow.Subscriber; import java.util.concurrent.SubmissionPublisher; import java.util.stream.IntStream; public class Sample { public static void main(String[] args) { SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>(); // Subscriberの生成と登録 Subscriber<Integer> subscriber1 = new SampleSubscriber<>("Sub1"); publisher.subscribe(subscriber1); Subscriber<Integer> subscriber2 = new SampleSubscriber<>("Sub2"); publisher.subscribe(subscriber2); Subscriber<Integer> subscriber3 = new SampleSubscriber<>("Sub3"); publisher.subscribe(subscriber3); // データの登録 IntStream.range(0, 5).forEach(publisher::submit); // 非同期で処理が終わってしまうので、実行終了するまで一時的に待つ。 try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } publisher.close(); } }
Sub2: ForkJoinPool.commonPool-worker-1: 0 Sub2: ForkJoinPool.commonPool-worker-1: 1 Sub2: ForkJoinPool.commonPool-worker-1: 2 Sub2: ForkJoinPool.commonPool-worker-1: 3 Sub2: ForkJoinPool.commonPool-worker-1: 4 Sub3: ForkJoinPool.commonPool-worker-2: 0 Sub3: ForkJoinPool.commonPool-worker-2: 1 Sub3: ForkJoinPool.commonPool-worker-2: 2 Sub3: ForkJoinPool.commonPool-worker-2: 3 Sub3: ForkJoinPool.commonPool-worker-2: 4 Sub1: ForkJoinPool.commonPool-worker-3: 0 Sub1: ForkJoinPool.commonPool-worker-3: 1 Sub1: ForkJoinPool.commonPool-worker-3: 2 Sub1: ForkJoinPool.commonPool-worker-3: 3 Sub1: ForkJoinPool.commonPool-worker-3: 4 Sub2: ForkJoinPool.commonPool-worker-2: Complete. Sub1: ForkJoinPool.commonPool-worker-3: Complete. Sub3: ForkJoinPool.commonPool-worker-1: Complete.
最初、全部表示されへん!なんでや!って思ったら、非同期処理だから終わってるから表示されないやん!って事に気づいた。
Thread.sleep入れてるのは、そのため。
なんか全部見れる上手い手ってあるものかが気になる。
Filterまで紹介されていたけど、今回は基本的な部分のタッチのみ。
非同期は覚えておいて損はないと思う。
そのうち、ビルドシステムもJavaで書くようになるだろうね。
Gradleは、ピュアJavaじゃないけど、非同期での実装がやりやすくなると、効率的なビルドが実現できるのではなかろうかと、ココロの中で思ってる。
※もしかしたら、知らないだけで、もう出来てる?
ForkJoinPoolって、たしかスレッド管理のやつだったよね。
あんまり使われてるイメージはないんだけど、裏の仕組みで必須なのかな?
どっかでキャッチアップしないとダメだな。
最新Java情報局 - Java SE 9の非同期処理ライブラリ、新概念の「Reactive Streams」を学ぶ:ITpro
ForkJoinについて理解しておく
Being Geek ―ギークであり続けるためのキャリア戦略
2016.03.22
いつもの内容まとめ。
個人の意見もメモってるので、書いてないことも書いてある。
ギークな人とは、世界を明確に区別できる信条を持っている人。
システム思考を絶対と考える。
通用しないときは、もろい物ができあがる。
特に人間は、システム思考に当てはまらない要素を多く含んでいる。
キャリア > 目の前の仕事
今していること、これからすべきことを考えることは重要。
キャリアは、人事・上司の評価で充実するものではない。
ゴールを決めることで、道中にある決断をしやすくする。
なぜか分からないが、「3」には力がある。
経済は、社会・共産・資本。勉強は、やる気・根気・暗記。
キャリアも同じく3つ。
方向性、成長、成果。
成長するには、戦略が必要。
なんでも勉強するのは、時間がかかりすぎる。
また、成長しない人は、死でいるも同然である。
死んでいないかは、下記の内容をチェックする。
失敗から学び、恐れないことが成長することになる。
他人からの評価を高めるには、有言実行しかない。
ただ、有言実行は難しい。
頼まれたことを、相手が認めるまでやりきる必要がある。
または、できないことには「No」を言う。
安易な「Yes」は、信頼を得られないだけでなく、疲弊する。
いわゆるデスマーチが起こる。
Noを言う場合は、Noといったときの評価の低下と、Yesを言ってできなかったときの評価の低下を、天秤にかける。
成長は、今日が昨日の繰り返しになってはいけない。
成長の判断基準は、知識。
以下に工夫して新しいものができるかが重要。
知識を使いこなせるかが、大事。
クイズ番組は、知識を使いこなせてない人の集まりな感じ。
なぜそんなに分かるのに、それを使えないのか考えると、大した人ではないのだと感じる。
教授もそういう人が多い印象。
論文述べるのはいいけど、現場適用はあなた達が考えてくださいって姿勢に、ものすごく苛立ちがある。
会社が嫌いという理由では、転職するのに十分な理由ではない。
怒りは、まともな物事を考えられなくなる。
冷静なときに、出した答えが転職かどうか、よく考える。
いづれにせよ、質問の意図を正しく理解することが大切。
とりあえずしゃべるは、悪手。
いい加減なことをいうより、「わかりません」の方がいい。
質問の意図が分かって、答えが出ているなら、話すだけ。
その場合、簡潔に述べなければいけない。
面接とは、相手の情報を引き出す儀式。
面接官の情報も引き出す。
構造化された面接であれば、面接準備済みで、目的に沿って進む。
流れを読んで、質問の兆候を予測し、何を欲しているのか理解する。
構造化されてない面接の場合、面接官が準備不足。
面接が長くなりやすいが、その分、相手の情報を得られるので、攻略方法も発見しやすい。
知るには、人と話すしかない。
文化は、人が作るもので、人を理解できなければ、文化を知ることはできない。
会社の文化は、行動の結果できていることが多い。
会社の核になっている可能性が高いので、常に注意している必要がある。
キャリアの形成にも影響してくる。
転職=キャリアではない。
転職する理由が、キャリアアップって言っている人は、だいたいおかしい。
形成するキャリアの方向性が合わなかったなら分かる。
ナードとは、日本でいうところのオタクに近い。
何かに熱中して、物事に精通している人間。
マネージャとは、他人に干渉されながら仕事する人。
扱うものが、ビットから人に変わる。
やるべきことは、戦略的に考えて忘れること。
意図的に忘れても、問題が起きないような仕組みを作ることが仕事。
タスク管理は、大まかに把握しておく。
維持に手間をかけすぎない。
絶え間ない練習と、機転の良さ。
失敗は、よくあること。
複数の目を持った人と話して、可能な限り一般論に近づける。
沈黙を意図的に入れて、内容に区切りを入れる。
沈黙を恐れていると、早口になって何も分からないってことがよくある。
評価よりも中身を重視する。
期待されていることと、それが実際にできているかを見る。
エンジニアとして培ったスキルは、あまり通用しない。
今までと違うスキルが必要になる。
ミーティングの増加、抽象化のフィルタリング、変化球への対応。。。
膨大な知識と技術を持っている人の場合、いれば安心だけど、実際はいなくても問題ない。
正答なのか判断しにくくなる。
不測の事態が、発生したときに問題になる。
それを乗り切れれば、後人が育ってくる。
権力・影響力が強い人の場合、文化が変わるだけ。
情報痛が辞めた場合、情報伝達が悪くなる。
ギークになりたきゃ、戦略持って物事を学んでいくしかないってのが、読んだ感想。
何も考えずに仕事をこなしているだけでは、ギークにはなれないと感じた。
※この本だけから学んだわけではないが。。。
あと、ギークになろうと思ったら、組織にいると意外と障害があるのではないかとも思った。
それを避けて、楽してやりたいことをやるためにも、組織的な役割と問題の回避方法を知っておいて損はないだろうとも感じた。
毎度のことながら、よくお世話になるIDEなので、キャッチアップのために調査。
最近は、TypeScriptやっているせいか、Visual Studio Codeを起動することが多くなってしまったけどね。。。
今回は、地味めなデザインだな。
いつもは、キラキラした派手な画面の印象があるが。
日本語化 Eclipse 4.7 Oxygen オキシゲン | MergeDoc Project
全部は無理なので、気になった箇所だけ。
もっと知りたい場合は、参考サイトに貼ったリンク先が内容が濃い。
カバレッジ計測のプラグインであるEclEmmaが標準で装備。
EclEmmaにクセがあり意図しない挙動があるようだが、通ってないコードを見分けやすくなった。
以前に調べたことがあったので、そちらを参照してもらえればと。
いろいろ操作性が改善したらしい。
自分は根っからのSourceTree派なので、あんまり興味が沸かなかった。。。
説明は、下記のリンクを参照。
Eclipse 4.7 Oxygen 新機能 30+ / Java 9 を試そう! - Qiita
修正内容が、かなり多い。
Gitを覚えることの重要性が伺える。
ある特定のブレークポイントを通過した場合だけ、トリガーポイントに設定した箇所でとまるようになる機能。
機能の共通化している箇所で、特定のブレークポイントに入ったときにだけ、共通部分のロジックをデバックしたいことはあるはず。
それが、楽にできるようになったってことだろうね。
以前は、共通部分に入る前にブレークポイント貼って、止まったあとに、共通部分にブレークポイント貼ったりして、かなり面倒だった。
今までなかったのか。。。
eclipseは重いから、そもそも二重起動しようと思わなかった。
システム的に防止してくれるなら、誤操作で起動は減るかもね。
ウィンドウ > 設定 > 実行/デバッグ > 起動 から、「起動中に終了して再起動する」にチェックを入れる。
ワイルドカードの利用が可能になった。
マウス操作しがちだから、あんまり使わないが、覚えると楽なのはたしか。
今は潤沢なメモリもあるし、コマンドによるエディタ切り替えを、覚えて損はないと思う。
大変参考になりました。
リーンスタートアップに釣られた。
たぶん、自分がいましている開発もリーンスタートアップに分類されるような気がしたから、まとめメモと感想を書くに至る。
起業家が一番恐れることは、作ったサービスが顧客に届く前にリソース枯渇すること。
最初に考えたアイディアが当たればいいけど、そんなことは稀。
これを成功に導くために行う考えが、リーンスタートアップ。
やることは単純で、仮設→検証→修正を繰り返すだけ。
もしくは、構築→計算→学習とも表現される。
口で言うのは簡単だが、実際にやるとなったら大変。
やることは誰かに求められているものをリソース枯渇する前に作ること。
事業計画相当のものを1枚のキャンバスで表現したもの。
構成要素として下記の内容が存在する。
顧客にとって重要なのは、製品ではなく課題が解決されるのかどうか。
課題が明確化してないのに、それを解決できる製品は売れなくて当然。
そして、その課題をどのような顧客が持つのか具体化することで、付加価値を高めるのは何なのかを明確化できる。
どのように位置付けられるかを示す。
既に存在している別製品のメタ表現が期待されている。
課題を解決する機能。
ラフでOK
顧客へ届ける手段。
ビジネス起こすんだから必須の考え。
事業をどうやって成立させるのか考える。
製品の有効性を測るために見るべき指標を決めておく。
複数見ることもある。
段階や見るべきタイミングも考慮しておく。
強豪が簡単に真似出来ないものを考える。
起業家の視点が足りてないからだろうか?
あんまり頭に入ってこなかった感じ。
なんかのシステム開発に望む時は、ココらへんをもうちょい意識してやってみよう。
たいてい、隠されていて、何考えているのか分からんところが多いけどね。。。
何年もシステム開発できるとも限らないし、起業家の考えは早めに身につけたいな。
仕事でTypescript使っているけど、なんか仕事しても充実感?達成感が得られないので、考察した結果をメモる
やっていることは、データの橋渡し。
ハードからあがってきた情報を、クラウドへ打ち上げる前くらいのところを担当している。
クラウド上に展開されているアプリに食わせるために、データを加工しているのが主な仕事かな?
あとは、ハードからあがってくる情報を抽象化するってのもある。
おそらく、グルーコードばかり書いているからだろうと思われる。
なんというか、結果がダイレクトに見えるところじゃないからかも知れない。
ハードは、操作が関係してくるから、作ったら操作して動けば、嬉しいと思う。
しかし、俺が作っているのは、ハードの凄いコードが打ち上げてくるデータの加工。。。
どうしても、ハード側のコーディングの方がすごそうに見えてしまうってのが、心の中である。
前まではJavaばかりやってきたので、ネイティブ系のプログラミングには、憧れがあるのかも知れない。
Javaエンジニアなら、共感してくれる人が多いと信じたい!
無性にWebと関係ない箇所のプログラミングをやってみたいって感覚に、とらわれる事がある。
やっていることは、重要なことだと思うけど、それを実感しにくいんだよね。。。
バグが起きたら、障害切り分けのために真っ先にこっちに問い合わせがくるのも、結構シンドイ。。。
最初は、分かんないことが多すぎて、いろんな人に聞いて回ったりするのが、心理的にくるものがある。
おかげで、全然関与してない部分のログを見れるようになってしまった。
書いて思ったが、意外と俺凄いんじゃね?って思えてきた。
実感しにくいのが、問題だね。。。
振り返ると、意外と凄いことしてたんだなと思う。
システムの全体像を把握しているわけなんだから。
ただ、自画自賛はちょっとキモいって感じるけどね。。。
仕事で充実感を得られなかったら、たまに振り返って、やってきたっことを見直すのはありかもしれない。
成果が見えにくいならなおさら。
たまに、振り返りの機会をもうけようと思う。