「アイアンバディ（全4巻）」「ATOMの開発現場に潜入せよ（全1巻）」。将棋とセガサターン。サターンエッセイ「第六惑星から」も描いてます。 漫画http://pixiv.me/reureu0721 ご連絡はreureu0721＠yahoo.co.jpまで
Apache Kafka More than 80% of all Fortune 100 companies trust, and use Kafka. Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. Manufacturing 10 out of 10 Banks 7 out of 10 Insurance 10 out of 10 Telecom 8 out of 10 10/10 Largest insurance
ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。 browserifyが生まれ、Gruntが生まれ、Gulpが生まれた。 そしてその全てが死んだ。 Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。 一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。 そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプターを自称し最新技術のケツを追いかけQiitaにクソを垂れ流す彼らこそ我らがイケイケウェブフロントエンジニアである。 最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれた
NVIDIAによる開発者向けカンファレンス「GPU Technology Conference（GTC2014）」。2日目の基調講演にはアニメーションスタジオとして知られるPixar社が行なった。 The Foundry社の「KATANA」と呼ばれるツールを使ってライティングを編集する。左側の画像がプレビューで、たとえばカメラ位置を変えてもリアルタイムに画像が変化する。レイトレーシングは、視点へ向かう光を計算するものなので、カメラ位置が変わると再計算が必要になる。こうした処理をGPUで高速化しているとのことだ もともとハードメーカーだったPixar CG制作事業は業績悪化の結果での新規事業 そのPixarは実は創業当時はハードウェアメーカーだった。製品は「Pixar Image Computer」で（英語版Wikipedia）、もともとはルーカスフィルムの一部門としてCGツールの開発にあた
今年のピクシブ株式会社には総合職 2 人とデザイナー 2 人が新卒として入社しました． そんなフレッシュな新卒に新卒エンジニアがプログラミングの基礎を教えろというお達しが出ました． ということで秋卒業で既に入社していた私（@catatsuy）とアルバイトから入社した 2 人（@geta6/@RooandQoo）の合計 3 人中心でプログラミング初心者向けに研修内容を考えました． 題材 @tarbrick からのリクエストで最終目標は『画像投稿掲示板を作る』ことに決まりました． 方針 今回のプログラミング研修の目的は総合職・デザイナーの人たちをエンジニアにすることではありません． エンジニアの人たちが普段の業務でどういったツールをどういった流れで使っているのかを学ぶことで，円滑にエンジニアとコミュニケーションを取れるようにすることが目的です． そこで方針として以下のものを決めました． 全員
![非エンジニアの新卒にプログラミング研修を行いました - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/f916361b650069fb11afbce59202ffa77b38093e/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F60818056dbe64ed2ba892c0765fdca840a7ffa03%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fc%252Fcatatsuy%252F20140428%252F20140428171910.jpg)
なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」
http2.0勉強会に行ってきた。面白かった。なんだかね、勉強会の雰囲気がよかった。人数が少なくて、ゆるくて、濃い。いいね。 http2.0 勉強会 - connpass tweetまとめた。 http2.0 勉強会 - Togetter 内容はこんな感じ。 HTTP2.0 の基本的とこれまで @jxckさん ヘッダ圧縮とネゴシエーションの話 @flano_yukiさん httpbisってWGはこんな風にCrazyな場所なんですよ？ @lefさん httpbis interim と相互接続試験の話 @jovi0608さん 予習資料。もともとはdraft04だったけど、下のリンクはdraft05にしちゃった。 draft-ietf-httpbis-http2-05 - Hypertext Transfer Protocol version 2.0 wg_materials/interim-1
伝聞。 あるソシャゲ会社のプロジェクトのひっくり返り方。 １年目 新卒に運営の手伝いをさせる。 ２年目 運営を切り盛りさせる。 ３年目 開発の頭をやらせる。 （実際にはそれぞれ６ヶ月ぐらいと思われる） そりゃひっくり返るわ。 何一つ開発で学んでないじゃんか。なぜ開発ができると思うんだ。 運営業務はウィークリーでデイリーなので、関わってると運営に関しては結構いいスピードで詳しくなるが。 開発は少なくとも数ヶ月かかるので。詳しくなるには何本かの完成に付き合う必要があり数年を要する。 絵でも漫画でもゲームでも。１本仕上げる度に能力がつく。 １本まるっと面倒見ないと、それを作る間にどういうコストとリスクがあるのかを肌で理解できない。 どういうトラブルが発生し、それをどう解決したかの蓄積がたまらない。 そもそも今あるトラブルがどれぐらいのトラブルなのかも見当がつかない。 イベント１コつくるのとゲーム
The Polaris Dawn crew is back on Earth after a historic mission
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
絨毯爆撃pushの例 いまmasterブランチに、未プッシュのコミットがあるとします。 ここで、新たにbr1ブランチを作ってチェックアウトします。 $ git checkout -b br1 master $ git branch * br1 master br1ブランチでコミットを作ります。 echo hello >> hello.txt git add . git ci -m "add file" 引数なしでプッシュします。 git push すると、どこに何がpushされると思いますか？ 実は、master -> masterにpushされます。 masterがまだpushできる状態でない場合、これはかなり痛い。すごく痛い。頭が頭痛でおなかが腹痛。 しかもpushしたかった当のbr1ブランチはpushされないというオチ。(リモートにbr1ブランチがない限りは) この挙動は大半のユーザ
programming notes. mainly about JavaScript / jQuery. [@Takazudo] [takazudo@gmail.com] Hint: alt + / ※ このブログの内容は弊社が運営する有料サービス、CodeGridにてより詳しい内容をご参照いただけます（宣伝） jQuery deferredの使い方 - deferredの基本 | CodeGrid === jQuery1.5から追加された機能。でも全然使ってないので調べた。 jQuery1.5からはdeferredオブジェクトっていうものが登場。 これは、「イケてるキュー（待ち行列）の仕組み～遅延もあるよ～」みたいなものです・・・ 説明がムズイけれどもなんかそんな感じなのです。今までは function fetch(callback){ doAjaxThings('somefile.js
必殺！Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル（？）な GitHub を利用しています。（GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。） ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。（で
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
新社会人の皆さん､いかがお過ごしでしょうか｡ 最近､SIerに就職した知人が｢会社辞めたい｣というのをちらほら聞く｡聞いてみれば､彼等は仕事で挫折しているわけではない｡むしろ､技術に優れ熱意を持っている事が多い｡ではなぜ辞めたいのかと聞けば､一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて､｢ああ､そっか…そうだよね…｡｣となる｡ そんな時は､SI業界の熱い人達のスライドを見て何かを感じよう！という事で4つ選んでみた｡弊社関係者が多いのは僕のネットウォッチの都合上お許しください｡moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド｡｢自分の生き方を他人任せにしない｣受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス
The Gumroad API is based around REST. We return JSON for every request, including errors. We also use HTTP response codes to indicate errors. We've tried to make it as easy to use as possible, but if you have any feedback please let us know. To first start using the Gumroad API, you'll need to authenticate your session:
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus): 大塚 弘記: 本
