はてなブックマーク

英語でよくある、いいこと言ってそうに見えるけどなんかプッとくる名言みたいなのが好きで集めていた。職場での息抜きにそういう一文をslackに貼り付けるのはよくやっていて、面白いからまとめてウェブサイトにした。 エンジニアの名言メーゲン https://www.meigen.ga/ バックグラウンドにきれいな景色の写真を入れて無駄に「いいこと言ってそう」な雰囲気にした。 名言は人気順ということでツイート数順に上から並べている。もし気に入ったのがあって、ツイッターで共有していただければ順位が上がりますよ、と。 無料だから.gaでドメインを取った。「名言. ガー」とでも覚えてください。 https://www.meigen.ga/ ボタンひとつで英語版に切り替わるので英語の勉強にもどうぞ。（学習効果の保証は一切無し） ほんとただの趣味でしかないんだけど、集めているのでもし面白いのをご存知でしたらサ

映画の辛口レビューと感想を機械学習を使ってブログ記事から集めてウェブサイトにした。名前はホット チリ レビューズ。 現在は約３万件のレビュー記事と６千本の映画が収録されている。最終的には機械学習の精度を高めてレビューを集めまくって世界一の映画ブログ総合サイトにするつもり。 映画の感想と辛口レビューをブログから集計 ホット チリ レビューズ ウェブスクレイピング　＋　機械学習　＋　ビッグデータ　＝　なんかスゲーもの ３つの要素を足すと個人が立ち上げるウェブサイトであっても、すごいことができるはずという確信がある。機械学習はまだまだ学習中ではあるが成果が出てきたのでサイトを公開した。 映画レビューについて わりと映画のレビュー好きである。単なる映画好きとはちょっと異なる。あくまで「映画のレビュー」好き。
映画のレビューはそれだけで十分に楽しめるコンテンツになっている。必ずしも「レビューを読むこ

QiitaのAPIから投稿記事を取り出し、技術書籍を紹介している箇所を集計して、ランキングサイトを作った。作った本人が言うのも何だけど、できあがった技術書ランキングがやたらエンジニア指向で便利で面白いなー、と。 技術書ランキングをQiita記事の集計から作成した テック・ブック・ランク エンジニアにとって技術書の選定はまーまー苦労する。単なる発行部数ランキングでは「人気あるからって技術書として参考になるとはかぎらない」と、なってしまいがち。ブログでオススメされている書評なんかも参考にするが、結局それらは書評を書いた人の主観で書かれたのであって客観的指標にはなりえない。 そこで「Qiitaにある技術ブログ記事内で紹介されている書籍情報を集計すればひと味違った書籍ランキングになるのでは？」と考えた。 で、以下の条件に当てはまる本を「いい本」とした たくさんのQiita記事で紹介されている本 人

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GraphQLをサーバー側とクライアント側とで実装してみて得た意識すべきポイント３つについて。 ひとつのエンドポイント バージョン無し できるだけ薄く この３つを意識して実装するのとそれが無いのとでは実装スピードが何倍か違うと思う。特にREST脳な人の場合。 GraphQLは使い所さえあえばめちゃくちゃに有用で面白い。しかもGraphQLの公式サイトはとてもわかりやすく説明されている。その辺のブログ記事よりもよほど洗練されていて、技術に関してはここ以外に読む必要はほぼ無い。 しかしGraphQLを使いはじめた当初はなんか妙にコーディング

GraphQLは実装内容に合えばタイタニックの救命ボードのように混沌から救い出してくれる。だからと言って全てのプロジェクトがタイタニックな訳ではないので、使い所が合わなければそんな救命ボードにもあまり意味は無い、という話。 先日、個人開発して公開したプロジェクト「node-node-node」のバックエンドはRails APIにGraphQLを使っていて、このプロジェクト内容に対しては最高の親和性を発揮してくれた。 GraphQLのメリットを一言で言えば「クライアント＝サーバー間での複雑なトランザクション処理の全てをGraphQLが吸収してくれる」ということに尽きる。ややこしい技術の詳細を書いたところでメリットはこれ以外に無い。 /usersや/postsというそれぞれのエンドポイントにリクエストを投げていたのがRESTful。 GraphQLにするとエンドポイントを気にすることなく「これ

この記事はかつての私と同じように「Reduxを使った非同期処理がいまいち分かんねー」という方に向けて書いた。とりあえずはReactの公式サイト、Reduxの公式サイト、Dan氏のReduxビデオ解説を観たが、なんかスッキリしない。特にReduxの非同期処理が分からない、という方向けの超シンプル解説。 Reactは公式サイトのチュートリアルなんかも充実していて丁寧だし分かりやすかった。しかしReduxは違う。特に公式サイトの非同期処理の例が変にややこしい。 こういうことをブログで書くと「アタシは公式サイトの説明を読んでも分からないバカです」と言ってるみたいだから、恥ずかしいしあまり書かれない。ウザいぐらいに「Reduxは素晴らしい。シンプル。カンタン」という発言がネット上にあふれている。 しかし私の頭ではパっと分からなかった。私以外でも「これ難しいなー」と思ってる人が居るんじゃないだろうか。

Chef client-serverモデルの入門者向け解説。 いまだになぜなのかはよく分からないが、Chef-soloや Knife-soloの解説はよくあるのにChef client-server版の解説があまり見当たらない。英語で検索すればたくさんヒットするし、英語圏でChefはclient-server版が主流に感じる。実際、私の今の勤め先であるベルリンのスタートアップでもそんな何千何万のサーバ数ではなく、小規模な数のサーバ数だがChefはclient-server版を利用している。 日本語情報でChef-soloが主流なのは最初に誰かが日本語でChef-soloを解説して、そこから派生して誰もがそれに沿って環境を構築しているうちに日本語のノウハウがSoloばっかりに溜まって、どんどんそっちに行ってしまったのかもしれない。日本語書籍にしても決まったようにSoloばかり。なんかもったい

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Rubyのリファクタリングでオブジェクト指向設計に沿った美しいコードになるまでの方法を書いた。 コードの元ネタはBen Orenstein氏のリファクタリングで、そこに私なりの解説と追加コードを加えた。 Ben Orenstein - Refactoring from good to great このリファクタリングは大きく分けて３段階。 「イケてない」から「マシ」にする 「マシ」から「いいね」にする 「いいね」から「スゲーいいね」にする イケてないコード まず以下にあるのがイケてないコード。一応動くし、テストもパスしている。でもそのコード品質は平均よりちょっと下という設定。 【範囲を指定してその期間の売上総合計を出すコード】 class OrdersReport def initialize(orders, start_date, end_date) @orders = orders @

ここで言う「Railsの中身のコード」というのはRailsを使ったRailsアプリのコードではない。Railsそのもののコード。DHHが書いたRailsのコード。$ rails new AppNameとかのコマンドが動く仕組みが書かれたコードのこと。 これって職場の同僚と英語で話しててもいっつもゴチャゴチャと説明が要る。RailsアプリのコードとRailsの中身のコードを区別してそれが一発で分かってもらえる表現があったら教えて欲しい。 いいコードのコードリーディングはオススメ ご存知のようにそのRailsの中身のコードというのが巨大でなかなかにレベルが高い。初心者では読むのも一苦労でそこが遠ざけてしまう原因にもなっている。それでも優れたコードをコードリーディングすることはいい勉強になるのでオススメ。 いかにコードリーディングが重要かは、いろんなブログなんかで優秀なエンジニアの方々が再三強調

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 海外転職の技術面談の形式に関してはこちらのブログに何度か書いたので、今回はその具体的な対策を書いた。ずばり「RubyとRailsに関する英語の基礎質問と解答例」 書類選考をみごとに通過したら次は電話面談かもしくはオフィスでの面談になる。いづれにしても採用側の会社からはエンジニアが２，３人ぐらい出てきて応募者の相手をすることになる。最初は本当に基礎的な技術質問から入る。それは誰にでも分かるような質問と答えで応募者に話してもらって緊張をほぐす意味と、あともうひとつは「箸にも棒にもかからない人に早々とご退場」願うためだ。あくまでメインは技術質

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

英語を使って海外のエンジニア職に転職しようとする際に避けては通れないのが技術面談。もし海外のエンジニア職への挑戦をお考えの方でそれが初めての場合、この技術面談の対策は十分にとっておいた方がいい。 きっと思っているよりも実際にやるとその難しさを実感するパターンがこの技術面談。たまにYouTubeに技術面談をシミュレーションしている様子のビデオが上がっているが、なんか嘘くさいし、そんなビデオを横から見ても一体ナニをどうすればいいのか対策の立てようがない。 だいたいこの技術面談でその応募者の相手をするのは現役バリバリのエンジニアだ。日本のように転職面接に人事の人が出てくることはまずない。エンジニアの技術レベルを測れるのはエンジニアだけ、という当たり前な理由なんだけど。とにかく現役のエンジニアがこれでもか、というぐらいにあなたの真の実力を読み取ろうとしてくる。 技術面談で出される問題は大きく分けて

TensorFlow TensorFlowはGoogleがオープンソースとして公開した機械学習のライブラリ。 www.tensorflow.org ここしばらく機械学習の本読んで、TensorFlow触りまくって出した結論はこれ。 TensorFlowは機械学習の初心者がスグにカンタンに使えるモノではない TensorFlowを使えば機械学習の概念をそのまま直感的にコードに落としこむことができる。ただ、そのためには機械学習の理論を予め知っておくことが必要。「ニューラル・ネットワーク」とか「構造パターンマイニング」とかの用語が分からないといちいちそこで手を止めて、調べる必要が出てくる。 ただ数学好きであれば、全てが数式で表現される世界が妙に楽しい。アルゴリズムや使い方さえ分かれば、かなりのレベルで面白いモノが実装できることは確かだ。 TensorFlowのインストール（MacOS編） まーこ

毎年スタックオーバーフローから世界中のITエンジニアを調査対象とした調査結果が出る。基本は英語圏のエンジニアに向けた調査になっているので、日本のエンジニアの現状とを比較する際にはとても参考になる。 人気のテクノロジー この手の調査結果ではいつもJavaScriptが１番。Javaも常に高順位にいる。PHPが５位の25.9%と意外にまだまだ人気な様子。 嫌いなテクノロジー 好きなテクノロジーの次のタブがこの嫌いなのランキング。トップ２がVisual BasicとWordPress。個人的にもこの２つにはあまり関わりたくない、という思いがある。 エンジニアの年齢 若い。。。中央値は２７歳。２７過ぎたらもう老人扱い。 エンジニアの皆さん、年食ったらフサフサな髪のズラかぶって、エステ行ってシワのばして若いフリしましょう。辛いですが、そういう世界らしいです。 どっちが好き？スターウォーズ VS スタ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 世界の凄腕エンジニア、科学者が講演や本で語ったプログラミングに関する言葉を集めた、「凄腕エンジニアのお言葉集」は不思議にココロを打つのでまとめた。 たった一言でもその言葉を発するまでに作ってきたすごい製品や打ち出したすごい理論の上にある、と思うとなにかずっしりとその言葉の重みを感じる。 シンプルな方がいいんだよ Simpler is usually better - Rich Hickey Rich HickeyはClojure作った人、そうそうシンプルがいいんですよ。分かってはいるんだけど、なんかいつの間にか複雑なコードになってしまっ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね？という話。 ここで言う「ハマる」とはなにかに夢中になって没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。 先日、ハマった問題が解決した時の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが！」という前任者への怒りが混ざった状態だった。 サイトのSSLの有効期限切れが２週間後にせまっていた。やる事は証明書の更新、新しい証明書をAWSのELBに入れるこ

公開鍵暗号の仕組みをまとめることにした。 先日作成して公開したエンジニア向けのパズル８は公開鍵暗号の仕組みを使っている。RSA暗号のコード書いてデバッグして、暗号の仕組みをかなり理解したので、せっかくだからまとめた。 公開鍵暗号 金庫の中にに大事なモノを保管する時、まずは金庫を閉めて鍵をかける。すると鍵を持っている人にしか開けられなくなる。これが通常の鍵の仕組み。 ただネットを介した通信での暗号方式では少し事情が異なる。 まず送信者が金庫を閉めて鍵を使って鍵をかける。そしてそれを受信者に届ける際には金庫と鍵を送ってもらう必要がある。しかし金庫と鍵を同時に送るのは危険。途中でその鍵が見られたりコピーされたりしたら、金庫に入れる（暗号化すること）意味が無くなってしまうからだ。大事なモノに鍵をかけて送るのに、その鍵を送る方法が無防備だとまったく無意味になってしまう。 そこで数学者の叡智により編み

#パズルができた訳 今シンガポールのスタートアップでエンジニアをしているのだが、半年ほど前にソフトウェアエンジニア向けの求人募集ページに簡単なプログラミング系のパズルを出して、それが解けた人だけ応募できる仕組みにしよう、という話になった。 その時期は求人を拡大募集していたのだが、あまりにハズレな人が多かった。私もいくつか面談をしたのだが「CV（履歴書）には高いスキルって書いてるけど、言ってることがなんでこんなに変なの？」と感じてしまう応募者が多かった。これは私だけの意見でなく、他のエンジニア達からも不満が続出した。つまり履歴書のスクリーニングが効いてないということだ。日本よりも海外の方が履歴書を誇張する率が高い気がする。そこで考えたのが求人募集ページにエンジニア向けのパズルを出す、という発想。 #パズルのコンセプト 言ってはみたもののどんなパズルにしようかと考えると案外難しい。 パズルの条