Stop learning frameworks
comments We are developers. We need to stay up to date with technology. Every day, we learn programming languages, frameworks, and libraries. The more modern tools we know — the better. Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun. But we are wasting our time. Time is the most precious resource we have. Time is limited, nonrenewable and you cannot buy more of it. Techn
tigの車輪の再発明 - the code to rock
複数ファイルが立ち並ぶディレクトリにおいて、1つまたはいくつかの限られたファイルだけを`git add`したいという場合、いちいちそのファイル名を打ち込んでいくのがメンドイ。 こういう時、peco的なものでバッとリストを出して、インクリメントに対象を絞り込みつつ直感的に選択できないものか？ と思っていた。 で、こういうのを作った。（コマンドは`ga`） Perl製。 とくにリポジトリを公開したりしていないので、生コードはこんな感じで。 （.bashrcと組み合わせる） # .bashrc function gi { local arg="$@" local pick=$(perl /path/to/gi.pl) #パスは任意の場所で if [ -z "$pick" ]; then echo Canceled. elif [ -z "$arg" ]; then echo Input a co
Modern JavaScript概観、そしてElectronへ | さにあらず
この一か月分の学習成果を整理したリポジトリを作ったので、その成果についてまとめておく。 作ったサンプルプロジェクトだけを手軽に欲しければ、このリポジトリを clone してほしい。 taichi/js-boilerplatemaster ブランチには、ミニマムな JavaScript 開発環境がサンプルコード付きで入っているfrontend ブランチには、React/Redux/webpackなウェブアプリケーション用の開発環境が入っているデフォルトブランチにしてある electron ブランチには、frontend ブランチの内容に加えてElectronでアプリケーションを開発するための環境が入っているはじめに#最近の JavaScript について#僕は仕事として JavaScript を書いている訳ではないけども、この半年くらいの間にちょっとしたツールならいくつか作った。どちらも便利
Talks that changed the way I think about programming – Oliver Powell
The best teacher I had in graduate school spent the whole semester destroying any beliefs we had about computing. He was a real iconoclast. He happened to be a genius, so we took it. At the end of the course, we were free because we didn’t believe in anything. We had to learn everything, but then he destroyed it. He wanted us to understand what had been done, but he didn’t want us to believe in it
エンジニア立ち居振舞い：重箱の隅をつつかない - 面白コンテンツ探求日記
お題「エンジニア立ち居振舞い」 自分は重箱の隅をつつかないというのを意識してる。 重箱の隅をつつく問題はコードレビューの現場でよく聞く。レビューの場で所詮「書き方レベル」の指摘が横行してしまうというやつ。 誰しも綺麗なコードを追求したい気持ちはあると思うし、自分もそうなんだけど、あまり良くないなと思ってやらない事にしてる。理由は3つ。 時間の無駄 指摘される側の精神衛生上よくない そもそも意味ない 細かい指摘でも修正してマージするまでには結構時間がかかる。コードを直し、手元でビルド・動作確認し、pushしてCIを回し、「修正しました」と報告し、LGTMが付いてやっとマージできる。このプロセスが日に何度も発生すると確実に時間を食ってしまうし、Nitsな内容を何度も何度も受けると精神的にも疲弊してしまう。それで生産性が下がってしまえばもっと大きな問題になる。 こうした指摘をしたくなる時、「コー
Why is printing "B" dramatically slower than printing "#"?
I generated two matrices of 1000 x 1000: First Matrix: O and #. Second Matrix: O and B. Using the following code, the first matrix took 8.52 seconds to complete: Random r = new Random(); for (int i = 0; i < 1000; i++) { for (int j = 0; j < 1000; j++) { if (r.nextInt(4) == 0) { System.out.print("O"); } else { System.out.print("#"); } } System.out.println(""); } With this code, the second matrix too
知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを
Cookpad Tech Conf 2016 に行ってきた - kentana20 技忘録
1.23 に恵比寿で開催されたCookpad Tech Conf 2016に行ってきました。 公式ページは こちら タイムテーブル No Theme Speaker 1 基調講演: ユーザーのために、技術をどう活かすか 舘野 祐一 ( @hotchpotch ) 2 おでかけスポット検索のむずかしさ - Holiday を支える検索技術 内藤 雄介 ( @Yu_7110 ) 3 Railsアプリ開発環境の高速化 国分 崇志 ( @k0kubun ) 4 R&D at Foodtech company 有賀 康顕 ( @chezou ) 5 技術力を事業の強みするために必要なこと 大野 晋一 6 開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法 五十嵐 啓人 7 「今日なに作ろう？」を支えるデザイン 木村 真理 ( @mura24 ) 8 確かめながら作る
PHPの生みの親、ラスマス・ラードフ氏インタビュー | gihyo.jp
PHPの生みの親、ラスマス・ラードフ氏インタビュー 2015年12月に無事公開されたPHP7。その公開に先立ってPHPの生みの親であるラスマス・ラードフ氏に話を伺う機会がありました。英語で行われた一時間のインタビューは長大ですがラスマス氏の思想がよく分かる話題が多く、可能な限りそのままの形でお伝えすべく、その模様すべてをお届けします。 なお、インタビューは10月に開催されたPHPカンファレンス2015の講演終了後に行われ、リリースに関する話題などはその時点でのものです。 現在の仕事と生い立ち ―――― まずは、PHPを作ってくださってありがとうございます。今日の基調講演もすばらしかったです。 ラスマス：ありがとうございます。 ―――― いきなりですが、個人的な質問から始めてもいいでしょうか。 ラスマス：どうぞ。 ―――― Etsyではどのようなお仕事をなさっているんですか？ ラスマ
たかがレシピサイトに何故こんな技術力が必要なのか - クックパッド開発者ブログ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 たまにネットやイベントなどで「たかがレシピサイトになんでこんな技術力が必要なのか」と言われることがあるので今日はそれに真正面から答えてみようと思います。 例えばどういうところで技術使ってるか 他の人の話はこのブログの他のエントリを見てもらえればわかると思うので、僕の所属しているクックパッド編集室での取り組みの中から今回は料理動画を例に説明します。 Adaptive bitrate streaming での配信 クックパッドで配信している動画は基本的に「料理動画を支える技術」でも触れられている配信プラットフォームを利用しています。 ここでは裏で動画を「低画質」「普通」「高画質」の 3 パターンでエンコードして、回線状況に応じて最適な画質の動画を HTTP Live Streaming (HLS) で配信してい
Rails開発におけるwebサーバーとアプリケーションサーバーの違い（翻訳） - Qiita
はじめに 先日スタック・オーバーフローでこんな質問に回答しました。 webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません 質問者の方はwebサーバー、アプリケーションサーバー、Rack、Unicorn、Pumaと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探していたところ、以下の記事を見つけました。 A web server vs. an app server - Justin Weiss スタック・オーバーフローでは記事の一部を抜粋して「ざっくり翻訳」したのですが、それだけで終わらせるのはもったいない気がしたので、Qiitaには全文を翻訳して載せておこうと思います。 これを読むと、あなたもwebサーバーとアプリケーションサーバーの違い
「参照透過である」とは、何から何への参照がどういう条件を満たすことを言うのか - Qiita
関数型プログラミングが流行していることもあって、頻繁に耳にする「参照透過性」という用語について考えます。 ∥ 参照透過性 - Wikipedia その過程で目にした、Stack Overflow 上の Reddy 氏の発言が面白かったので、ザックリと訳します。 用語の起源と、それがプログラミング言語に導入された経緯 一応意味は分かってはいるんですが、なぜ「副作用のない関数呼び出し」やら「変数への再代入の禁止」といった特性を「参照透過性」と呼称するのかが分かりませんでした。この場合の「参照」は、何が何を参照することであり、また、それがどういう状態にあることを「透過である」としているのかが、通り一遍調べてみても分かりませんでしたので、掘りに行ってきます。 英語版 Wikipedia の方には、この考え方がプログラミングの概念として導入された経緯についての論文が参考文献として挙げられています。
機械のためではなく人のためにコードが書けるかーーGitHub CEOのクリス・ワンストラス氏にインタビュー - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
会場に1,000人が集まった「GitHub Universe」 オンライン視聴者を含む延べ人数約15,000人が参加した「GitHub Universe」。そのほとんどがエンジニアなのかと思いきや、登壇者のリストを見てもわかるように、今ではNPOや自動車メーカー、NASAなど様々な企業やプロジェクトがGitHubをコラボレーションツールとして活用しています。これまでにGitHubが使われたプロジェクトの総数は、2,700万件に及びます。 2012年、世界有数のベンチャーキャピタル「Andreessen Horowitz」の共同ファウンダーであるマーク・アンドリーセン氏は、“Software is eating the world”と予見しました。それが今まさに、GitHubのような立役者のもとで現実のものになりつつあります。ソフトウェアが世界を食い尽くしていく。 「これからは、全ての企業が
国語力とプログラミング力の関係 解説編
2009年1月、Cyan設計者 林拓人氏とLispの伝道師 竹内郁雄氏との対談「Cyanを設計した高校生、5カ月で5つの言語を習得」が大きな反響を呼んだ。その原因の1つは、竹内氏が発したひと言「わたしの持論ですが、国語ができる（＝日本語できちんとした文章が書ける）人じゃないとプログラムは書けない」だ。これについてネットでは同意する意見が多かったものの、記事中で根拠が明らかにされていなかったため議論が紛糾した。そこで編集部は竹内氏に詰め寄り、「わたしの持論」について詳しく説明してもらうべく寄稿をお願いした。国語力とプログラミング力には本当に相関関係があるのだろうか。 事のいきさつ～Cyan設計者 林くんとの対談で発してしまったひと言が思わぬ反響を呼ぶ Cyan言語で経済産業大臣賞を受けた開成高校の林拓人くんと対談（「Cyanを設計した高校生、5カ月で5つの言語を習得」）しているうちに、つい調
LL言語でのhot deployとJavaでのhot deploy - wyukawa's diary
JVM Operation Casual Talksで出てた話としてJavaでhot deployってどうしてんの？ってのがありました。 hot deployっていうのはアプリケーションコードを変更してもAPサーバーを再起動せずに反映する技術です。 この辺別に僕は全然知らないし答えを持っているわけではないですが、まあちょっと興味があったのでLL言語でのhot deployとJavaでhot deployを簡単に調べたのでメモっときます。 コードを変更してAPサーバーを再起動する場合、APサーバーが止まっているときにアクセスが行くと困るので、ロードバランサから外してAPサーバーを再起動してまた戻すみたいなことをやるのがオーソドックスな方法のようですが、hot deployだとそういったことをやる必要が無くなります。 Server::Starterから学ぶhot deployの仕組み - $s
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
RubyWorld Conference2013まつもとゆきひろさん基調講演メモ | ちんぶろ
初めて参加しているRubyWorld Conference 2013での、Ruby創始者Matzことまつもとゆきひろ氏の基調講演『Aiming the Moving Target』が技術者にとどまらずいろんなひとに聞いてもらいたいような内容だったのでメモを放流。 体裁はあとで整え…るかもしれないし整えないかもしれない。 以下、聞きかじりメモ。 大学卒業後、2000人規模の大手システム会社に就職、エンタープライズ向けの大規模開発を手がける。 ウォーターフォール型の開発で初めから終わりまで3年くらいかかっていた。 →ここに疑問を抱く「なにか間違っている気がするが、なにが間違っているのか説明できない」 なにが間違っていたのか？ なにを作っているか把握していると思っていた 実際にはソフトウェアが一体なんなのかを十分に理解していない 物理的法則に制限されないのでどんどん複雑な構造になっていくのでドキ
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「煽って盛り上げるのは“自分がその技術を使いたいから”なんです」－Increments 竹馬光太郎(mizchi)氏 - Forkwell Press