齢30を越えてようやく気づいたWebエンジニアの勉強に関するベストプラクティス - おうさまのみみはロバのみみ
…を書こうと思っていた矢先に↓が投稿された。 しかもぼくが書こうとした内容よりも理論付けられていたり、充実した内容だったり、深掘りされてたりして非常に良いのでこれ読めばだいたい終わるし書かなくていいじゃんね！ってなった。 完。 employment.en-japan.com これを読んだあとで「あーこんな良いエントリあるならぼく書かなくてもいんじゃね？っていうかぼくも知らない内容書かれてて充実度で完敗だし書く必要性無くね？？」とか思って書かないでおこうかと思っていたのだけども 別にぼくが似たようなことを書いてもPV数やまとまっている内容の充実差で件のエントリに微々たる影響を及ぼすこともなかろう、あと単純に書いて頭の中を整理しておこうと思い直したので今書いてる。 タイトルは元々の主旨なのだけどそれは↑を読めば満足できると思うのでこのエントリはそこからちょっと外れているものを書いておこうと思う
一日8時間、60日間ペアプロしてみて思った日常ペアプロのコツ. 一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミン… | by Naohiro Oogatta | Medium
一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基本的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 （ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program
メソッド名をシンプルにするために、 知っておくと便利な英語のprefixとsuffix - codic ブログ
メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();
Known unknowns
“Systems Performance: Enterprise and the Cloud” をずっと読んでいる．この本はNetflixのBrendan Gregg氏がJoyent時代に書いた本である．その名の通りLinux（とSolaris）のシステムのパフォーマンスの本である（とにかく一つ一つが丁寧かつ深く解説されておりページをめくるごとに学びしかないのでパフォーマンスに関わるひとは今すぐ読むと良い）． この本で一貫して現れてくる，通底するのが，known-knowns，known-unknownsそしてunknown-unknownsという概念である．元ネタはDonald Rumsfeld 氏の会見でのコメントだが（cf. There are known knowns），複雑なシステムのパフォーマンスの重要な原則を集約している．良い概念なので簡単に紹介する． それぞれをパフォーマン
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
大規模ソースコードの読み方
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
流行中のテクノロジーはコレだ！改革をもたらすテクノロジー11選 | 株式会社VASILY(ヴァシリー)
Technology Radarの2015年1月版から厳選したGo lang, React.js, Swiftなどの11のテクノロジーを紹介した記事先日 ThoughtWorks社 から最新の技術動向をまとめた Technology Radar の2015年1月版が発表されました。 このTechnology Radarですが毎回、『技術』『ツール』『プラットフォーム』『言語・フレームワーク』と4つの領域に分けて紹介しており、絶賛流行中もしくは今後注目されるテクノロジーなどが紹介されています。 今回はそんな『言語・フレームワーク』の領域から厳選した11の注目テクノロジーを紹介します。 はじめに 各テクノロジーは『Adopt』『Trial』『Assess』『Hold』という4つの階級のどれかに属しており、各階級は以下の意味を持っております。 ・【Adopt】企業での使用が推奨されるレベ
技術の見せ方について - skozawa's blog
入社してから初めて、3日間の開発合宿に参加した。 開発したものをどの程度書いていいか分からないのでとりあえず感じたことを書く。 今回の合宿で一番勉強になったのが「技術をどう見せる」か。 合宿では、普段業務ではあまり行っていないデータ分析や、自然言語処理やクラスタリングなどのちょっとした技術を使って開発をした。こうした技術を使って開発したとき、その結果をどう見せるか、技術が使われていることをどの程度見せるかは結構重要だと思う。 今回開発して感じたのは技術は見えてないくらいがいいなということ。あからさまに技術を押し出すと普通の人は引くと思う。UI的にはおもしろそうというのが伝われば十分で、その裏に実はこういう技術が使われているというのはエンジニアとか技術に興味のある人にだけ伝わればいいと感じた。初音ミクとかは音声合成という技術が使われているけど、初音ミクというキャラクターが前面にでていて、技術
力への意志 - mizchi's blog
(この記事は闇 Advent Calendar 2013 - Adventar の8日目です。) コンプレックスの話をする。 僕がプログラミングを始めたのは、2008年の夏、大学1年の夏休みだった。大学のサークルの新歓を巡ったはいいが、どこもかしこも絶望的につまらなくて、当時エンジニアとネットウォッチャーしかいなかったTwitterをみていると、彼らがとても楽しそうに見えていた。 だから僕はTwitter漬けになって、一人でプログラミングの勉強をすることにした。大学では最低限の単位を確保しつつ、とりあえずなんでもいいからアプリを作るぞと、はてブで流れてきたホットそうな技術をひたすら手につけてみた。とにかく、新しそうなものをやるという戦略だった。 最初にやったことは、ゲーム用だったWindowsのデスクトップマシンを潰して、ひたすらUbuntu8.04をインストールしては、Railsのサーバ
本当にあったプログラマとデザイナの怖くない話 in Fukuoka.php Vol.11 · けんごのお屋敷
Fukuoka.php Vol.11 に参加してきました。 リンク先にもあるように今回は NO PHP DAY ということで Fukuoka.php という名前を冠しながらも、誰一人として PHP の話をしなかったという珍しい勉強会でした。残念ながらUstreamの中継はなかったためオープンにはなりませんでしたが、いろいろと勉強になってたくさんインプットができたイベントでした。素晴らしい発表の数々は、後々各発表者の方より資料やブログが公開されると思います。Twitter では #fukuokaphp ハッシュタグで流れを追えると思います。 そんな NO PHP DAY な Fukuoka.php で僕も LT 枠をもらっていたので、ひとつアウトプットをしてきました。 プログラマとデザイナのコラボレーション Web 業界では、プログラマとデザイナが一緒に仕事をすることは多いと思います。一般的
#ぶつかり稽古 で発表してきた。 - パルカワ2
「俺の本気を見せてやる」というテーマで発表を、とのことでしたが、好きなように話していいぽかったので、好きなように話をしました。 好きな事なので、当然吉高由里子の話です。 遅刻をしないように早めに家を出たのに、乗ってる電車で人身事故が起き、50分ほど電車の中で待ち、駅に降りれるようになったので、タクシー乗ろうとしたら相乗りしてもいいですか？と声をかけられ、いいですよと言って横浜まで戻り、降りようとしたら「相乗りはルール違反だ」とタクシーの運転手さんに俺だけ怒られるしで、なかなかつらい事ばかりでしたが、ちゃんと間に合い、発表できました。 ひさいちくんを指名してよかった。 #ぶつかり稽古— Gosuke Miyashita (@gosukenator) 2013, 11月 23 この一言で全てが報われた感じがしました。 指名してくれたmizzyさん、運営スタッフの皆さん、ありがとうございました。
「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
プログラマは金魚鉢で泳ぐ - ふたつの教室
いやー、暑いっすね。こうも暑いと仕事の合間にちょっとひと泳ぎしたくなるって事でエクストリーム フィッシュボウルやってみるかーと思い、チームメンバー10人くらいで試してみました。 エクストリーム フィッシュボウルって何かというと、もともとはグループワークの手法で、数人が輪になってディスカッションしてるのを囲むように数人が観察する「フィッシュボウル」というのがあって、それをベースに考えられたものだと思います。(たぶん) で、エクストリーム フィッシュボウルではペアプロをしてる2人をみんなで観察するのですが、観察するだけじゃなくて、質問したり野次を飛ばしたり、実装するメンバーを交代したりしながら開発する手法です。あまり本とかでは見かけないですが、勉強会などで時折行われていたりします。 詳しくはainameさんの説明資料をどうぞ。 extream fish bowl チートシート(Gist) ちな
Knoh (ノウ) | The Knowledge Hub
最近はやっているオンラインカジノやカジノアプリ。スマートフォンや通信技術の発達のおかげで、いつでもどこでも誰でも手軽ギャンブルを楽しむことができるようになったのは素晴らしいことですよね。管理人が学生時代に最初に始めたギャンブルは麻雀でした。運と知性が織りなす絶妙のゲーム展開は、一度として同じにはならず、誰にもその勝敗の行方は分からない。かといって技術介入の要素が強いためやればやるほど上達もしてゆくあのゲーム性。麻雀を生み出した中国人を心底尊敬し、一時は中国語を必死に勉強したものです。たった13枚の手配の中に宇宙がある。大げさではなくそう感じていたものです。気の置けない仲間たちと夜通し麻雀を打ち続けるのは最高のひと時だったと今も思います。学生時代は基本点五で卓を囲んでいましたが、長時間、長い時は二日三日と続けて打ち続けると、雀荘に支払う卓代がバカになりません。ちょっとやそっと勝ったぐらいでは
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません
※このエントリは、Arata Kojima/NPO法人しゃらく さんが公開しているわかりやすい技術文章の書き方の改変です。 このページは、プログラムやコードなどを書く方々のために、分かりやすいプログラムを書くためにはどうすればよいのかについて説明しています。 1. 自分が伝えたいこと・訴えたいことを誤解しないように相手に読んでもらうにはどうするべきか。 2. プログラムを書くにあたって知っておくべきルールは何か。 3. プログラムを書く前にどのような手順を踏めば、分かりやすいプログラムを作れるか。 などについて参考にしていただければ幸いです。 プログラムを書く前に プログラムを書く前に次のことをしっかりとイメージしておく。 何を書くのか。 書こうとしている物は正確に何であるのか。 仮定して良い、必ず成り立つ前提（状況／状態）は何か。 成り立つ事が単に多いだけ／今はたまたま成り立っている、と
![[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません](https://cdn-ak-scissors.b.st-hatena.com/image/square/f9042ce188c6adf10bc5510036708350fbfa0c46/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fe6eb841fd971e91609ad99e751b726c65a84d0f0%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fi.creativecommons.org%252Fl%252Fby-nc-sa%252F2.1%252Fjp%252F88x31.png)
ゆーすけべー日記
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
太一のコードの読み方メモ
Site Under Maintenance
