GithubのPRや海外Slackチャンネルでチャット、はたまた英語圏のエンジニアとやりとりする等、英語で文章を書くことはしばしばあります。そんな時、自分がよく使っている方法について書きます。 先に一番大事なこと 大事なことは、英語はあくまでもツールだということです。伝えたい内容が重要であり、英文を書くことに時間かけることはエンジニアにとって不毛です。 よっぽど英語が得意な人でないかぎり、一から英作文すると時間がかかって本質的でないところで時間を消費するということです。 なので一から文章を考えるのでなく、なるべく"型"を知ることがポイントだと考えています。それを踏まえた上で御覧ください。 文章を書く アルクの英辞郎とGoogle, Githubを組み合わせる 恐らく多くの人がGoogle翻訳などを使って英文を作っているかと思うのですが、アルクの英辞郎と組み合わせるともっとはかどります。理由

ども、@kimihom です。 今回 Github を中心とした OSS 界隈で有名になるいくつかの方法やメリットを挙げようと思う。私自身はまだまだ未熟者で、できていない部分もあるので、参考程度に読んでいただけたら幸いである。 OSS 界隈で有名になること OSS界隈で有名になるとは具体的にどんなことかっていうと、「誰もが使っているライブラリを作った人」になるというのが端的な説明である。Ruby on Rails を作った DHH といったように、人気のOSS であればあるほどエンジニア界隈では知らない人はいないくらいなレベルに到達することができる。やがてそれに関しての勉強会やカンファレンスが開かれたりするようなレベルにまで達することもある。ギークなエンジニアの方々であれば憧れの一つとなるだろう。 んで、そうなるとどんな良いことが起こるかっていうと、自分が目指したソフトウェアを他の皆と作り

最近、Amazonのエンジニア採用担当者から連絡を受けました。Amazonは、ベルリンオフィスのチームのソフトウェアエンジニアの採用面接をしていたのです。 連絡を受けてから契約書にサインするまでのプロセス全体は、2カ月でした。採用プロセスで経験したことと、私が合格できた理由として思い当たることをお知らせしたいと思います。 この記事で、もし私が何か重要なことに触れ忘れていたら、ぜひコメント欄に書いてください。出来る限りの詳細を回答に書きます。 4月27日：最初の連絡 採用担当者からの連絡は、 LinkedIn 経由でした。ベルリンオフィスのチームのソフトウェアエンジニアを募集しているので、もし興味があれば、最新のレジュメを送って欲しいとのことでした。私は、常にレジュメを最新にしていたので、翌日、Eメールに添付して送りました。 彼女からの返信には、募集しているソフトウェアエンジニアの役割と面接

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これはなんですか？ これは「This is Why Learning Rails is Hard（Railsの習得が大変な理由はこれだ）」という海外記事に載っているマインドマップを日本語化＆リスト化したものです。 元記事には「Railsを習得するために必要な技術要素の一覧」を表す、以下のようなマインドマップが載っています。 長年Railsの開発に携わってきた人間として、このマインドマップは「うん、たしかに！」と非常に納得できる内容です。 ただし、サイズの大きな画像なので一覧性に欠けるのと、英語なので日本人にとってはぱっと頭に入りづらい点

新人の開発者が繰り返し突き当たるテーマがあります。プログラム言語を1～2種類勉強するのに時間を費やしたり、プログラミングの演習を行ったりすることに関して問題はないと感じていても、学んだことをどう応用していいのか分からずにいるのです。このことは、次のようなフレーズとしてよく耳にします。「プログラムの書き方は知っているが、何をプログラムしていいのか分からない」と。これに対する答えは、一般的に、「プログラミングの課題を行いなさい」、「オープンソースプロジェクトに貢献しなさい」、または、「ゲームを作りなさい」というようなものです。 プログラミングの課題を行うことは、知的ないい訓練にはなります。しかし新しいプログラムの開発方法を学ぶのにはあまり役立ちません。オープンソースプロジェクトに貢献するのは確かにステップアップになります。実際のプロジェクトがどのように構成されているか学び、プログラム言語の技術

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事の内容 オブジェクト指向は難しい！わかった気になって実践すると詰みます... ｳｷﾞｬｰ この記事は10年以上オブジェクト指向と戦った筆者が、通常とは異なるアプローチでオブジェクト指向を解説したものです。 筆者はJavaを使って本格的なシステム開発をしたことがありませんが、オブジェクト指向言語として最もポピュラーなJavaをベースにオブジェクト指向について解説させていただきました。 また、この記事の続編にあたります「なぜオブジェクト指向は難しいのか」を更に2年の時を経て執筆させて頂きました！是非こちらも一読していただけると嬉しい

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事の内容 この記事は多分とても退屈です。正しい名前付けの記事なのに、口を開けば「仲間」がどうだ「組織」がどうだと、説教じみたことをクドクドと説かれる内容だからです。 しかし、どうしても「正しい名前を付ける」ことと「仲間と共に働く」ということを切り離すことができませんでした。 経験上、自分にとって必要なことはいつも「関心のない場所」に眠っています。もしあなたがこの記事を読んで退屈だと思ったのであれば、もしかするとこの記事はあなたにとって必要なことなのかもしれません。 この記事は「わかりやすさの重要性」と「働くことの本質」の深く知り、

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

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

この記事は Math Advent Calendar 2015 の 14 日目の記事です。 他のブログが本格的な数学のお話を記事にしている中、僕はというとそんなに高度な数学の話ができるわけではないので、自身の数学との関わり方や、また今年に入って開催してきた プログラマのための数学勉強会@福岡 の振り返りとその今後についてを書いていきます。同じような境遇の人が少しでもこっち側の世界に足を踏み入れれるようになることを願って。 プログラマから見た数学の楽しさ アルゴリズムやディープラーニング、ビッグデータ、WebGL など、よく聞くいわば流行りのワードについて、そういうものを使った技術やサービスを見つけた時「実際、中身はどういう風に動いているんだろう？」という好奇心はプログラマであれば潜在的には誰でも持っているのではないでしょうか。それは私達プログラマが、普通の人よりもより身近に普段からそういう

$k$は定数で、だいたい0.04~0.06くらいです。Rの値によって以下のように分類できます。 Rが大きい: corner Rが小さい: flat R < 0: edge 図にすると、以下のようになります。 CSE/EE486 Computer Vision I, Lecture 06, Corner Detection, p22 これで手早くcornerを検出できるようになりました。ここで、corner検出についてまとめておきます。 cornerは複数のedgeが集まる箇所と定義できる 変化量をまとめた行列の固有ベクトルからedgeの向き、固有値の大きさから変化量の大きさ(edgeらしさ)がわかる 2つの固有値の値を基に、edge、corner、flatを判定できる 固有値の計算は手間であるため、判定式を利用し計算を簡略化する なお、Harrisはedgeの向きである固有ベクトルを考慮す

(訳注:2016/3/3、頂いたフィードバックをもとに記事を修正いたしました。) オープンソースプロジェクトでバグを見つけたとします。まずは、慌てずに落ち着きましょう。これは実によくあることです。ソフトウェアは人間の手で書かれるし、人間はミスを犯すものです。 または、こんなふうに考えるかもしれません。「やったね、バグの修正は大好きだ」。さっと現れて、何百万人とまではいかなくても、何千人もが使っているプロジェクトのバグを修正してしまうようなヒーローになりたくない人なんていますか？　オープンソースコミュニティに恩返しできたという温かな喜びを感じられる上に、一連の Github 履歴 ^(1) に追加得点を上げられるわけです。 *訳： 人気のあるプロジェクト 典型的なバグ しかしコーディングの初心者にとっては、オープンソースプロジェクトにコントリビュートするなんて恐れ多いことに思えます。私の友人

ここ数年、私はWeb開発と機械学習の自習に多くの時間を割いてきました。 学習のテーマは、Javascript、Node、ReactからPython、scikit-learn、ニューラルネットワークに至るまで多岐にわたりましたが、全てに対して私は一貫したアプローチで取り組みました。 そのアプローチとは、単純な（陳腐と言ってもいい）3ステップで進める、という手法です。しかし、 Web開発のシロウトだった私が5カ月で、プロだと自覚できるほどになった のはひとえに、このアプローチで臨んだ自習の成果だと思っています。 そこで私は、この自習法がほかの誰かのお役に立てるかもしれないと思い、少し記事を書いてみることにしました。 この記事は、何も分からないままやみくもに挑戦を始めた、2012年当時の自分自身に教えるつもりで書いています。 ステップ1：習うより慣れろ 新しいテクノロジを学ぶためにまず実行する最

注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS!　：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

こんにちは！デザイナーのきよえし(@kiyoe_furuichi)です。 この度10月でConnehito.incに入社して半年が経ちました！めでたい！ ほとんどJSが書けなかった私も今ではフロントもごにょごにょするデザイナーになりました。 良いタイミングなので今回のエントリーは、半年の間に学んだことの共有として、 デザイナーもできる、チーム開発で大切な「おもてなし」についてご紹介したいと思います。 チーム開発における「７つのおもてなし」 0. どうして「おもてなし？」 入社した当時を振り返った時、自分の開発過程やメンバーとのやりとりを見ていかに早く自分のタスクをこなせるかを優先した"オレオレ"デザイナー だったことに気づかされました。その衝撃をきっかけに、"チームとしてサービスを作り上げる"にはどうすれば良いのかを意識して考えるようになったんです。 それから、チーム開発で大切なことはメン

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？ また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？ 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 ま

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