不具合にテストを書いて立ち向かう - t-wadaのブログ
テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時
技術の見せ方について - skozawa's blog
入社してから初めて、3日間の開発合宿に参加した。 開発したものをどの程度書いていいか分からないのでとりあえず感じたことを書く。 今回の合宿で一番勉強になったのが「技術をどう見せる」か。 合宿では、普段業務ではあまり行っていないデータ分析や、自然言語処理やクラスタリングなどのちょっとした技術を使って開発をした。こうした技術を使って開発したとき、その結果をどう見せるか、技術が使われていることをどの程度見せるかは結構重要だと思う。 今回開発して感じたのは技術は見えてないくらいがいいなということ。あからさまに技術を押し出すと普通の人は引くと思う。UI的にはおもしろそうというのが伝われば十分で、その裏に実はこういう技術が使われているというのはエンジニアとか技術に興味のある人にだけ伝わればいいと感じた。初音ミクとかは音声合成という技術が使われているけど、初音ミクというキャラクターが前面にでていて、技術
エンジニアの心の闇を祓うマサカリ療法 - seri::diary
この記事は闇 Advent Calendar 2013の４日目です。 @seri_k 闇Advent Calendar書きましょう— ıɯǝɥɔʇoɥ (@hotchemi) 2013, 12月 2 心の闇なんてのは大体エンジニアに限らず社会人なら少なからずだれでも貯めこんでしまうものだと思う。どうすれば解決できるかなんて分からない。 ４日目の記事では、過去の自分が経験した心の闇の話と、それを祓う方法についてそれとなく書いてみる。 今いる会社のエンジニアは割りと生き生き働いている方だと思うけれど、それでもやはりどこか、斜に構えた考え方や、何かについての強いトラウマみたいなものを会話の中から垣間見ることがある。若いころに辛いデスマを経験した話だったり、顧客が会社に怒りに燃えて乗り込んできた話だったり、特定のミドルウェアのバグで大変な目にあったり、会社や顧客に理不尽な要求をされて喧嘩したり、と
コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード｜CodeIQ MAGAZINE
コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする
Post by @naoty
僕は、自分がほしいものを自分の手で作るためにプログラマーになったので、プライベートでの開発はだいたい自分が使うものを作ることに充てている。特にほしいものがないときは、そのとき興味のある技術を調べている。仕事が終わって寝るまでの時間や土日をそうやって過ごしているので、仕事の時間も合わせると四六時中プログラミングをすることになる。そんな毎日を過ごしていると、突然、電池が切れたかのようにプログラミングに対するモチベーションがゼロになるときがある。そのとき、僕はプログラマーとしての死を迎え、プログラマーでもなんでもないただの社会不適合者になる。3年余りかけて築いてきたスキルや実績がなんの意味も持たなくなり、わずかばかり存在した存在意義がなくなってしまう。そのような自分は自意識にとって到底認められない存在であり、底の見えない"闇"を感じる。なんとかしてプログラミングに対するモチベーションをかき集め、
力への意志 - 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さん、運営スタッフの皆さん、ありがとうございました。
プログラミングで使う記号の英語の読み方 [Updated]
“[ ]”などを個別に読む場合はleft/open bracket, right/close bracketと読んでください。 “<“はless than、”>”はgreater thanとも読みます。 Dave Thomasは”<<“を”less than, less than”と読んでいました。 “-“がdashなのかminusという話しについては、The difference between a dash and a minus signを参考にしてください。 あまり、この読み方はしないよ！とか、私はこう読むよ！とかあれば、@masuidriveまでmentionください。 [2013/11/21 14:00:00] 色々な方々にコメントを頂き追加しました。 速く・正確に読む ITエンジニアの英語 ITエンジニアの ゼロから始める 英語勉強法
スレッド・並行プログラミング/ マルチコア・並列プログラミングを学びはじめるためのN冊 - laiso
読みたい本のリストを作ってる(いくつかは購入済み)。 なんかおすすめあったら教えてください。 でもこういうのってリスト作って仕事した気になって満足してしまう。 並列と並行 学びはじめる前なんだから当然よくわかってはいないんでけど、並列と並行処理の違いは以下で認識してる parallel と concurrent、並列と並行の違い - 本当は怖い情報科学 parallel と concurrent 、並列と並行の覚え方 - まめめも (追記) 孫引きなんだけど「コーディングを支える技術 171P」に「プログラミング言語の概念と構造」から引用した記述があった ここでは並行→プログラミング上の概念、並列→ハードウェアレイヤーの話となっていますね。 並列処理・並行処理がプログラミングに必要な理由 マルチコアを生かしたパフォーマンスの向上 大規模なデータの処理 GUIアプリケーションのユーザビリティ
「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
スタートアップにとって、プログラミング言語の使用者数が多いということは問題なのだろうか？ - Line 1: Error: Invalid Blog('by Esehara' )
最近、とあるスタートアップのお手伝いを細々と続けている。自分は全く分からないのだけれども、ベンチャーの人材獲得が厳しいらしい、みたいな記事を読んでいた。そこであげられていた言語は、PHPとRubyだったが、自分はPythonを使っていて、結構仕事を探すのに苦労したりしていた。当然のことながら、自分のスキルセットが余りにもWeb向きではないし、さすがにポテンシャル云々とも言ってられない歳ではあるので、仕方ないかなと思いながら、今のベンチャーで、いろんな雑用的な仕事を行ったりしている。 で、そこのベンチャーで「Pythonの仕事なかなかないんですよねー」みたいな話をしたら、「あれ、Pythonの仕事、至る所にあるよ」と言われて、あれ、これって何かミスマッチが起きているのかなと思ったりもした。お金は寂しがり屋であるから、お金のある人のところにいくんやで、という話があったか、仕事も「元々仕事が多い
プログラマではありませんが、プログラマの話をさせてください - mixi engineer blog
はじめまして。8キロのダイエットに成功しましたが、最近リバウンド気味の土戸と申します。 私は今、弊社イノベーション・センター案件である、Plannah(プランナー)のプロダクトマネージメントとマーケティングに携わっております。 先日我がチームの開発メンバーである衣川から、簡単にPlannahの紹介がありました。多くの方々に記事を読んで頂き、そしてPlannahに関心を持って頂き、大変感謝しております。本日は、Plannahの話は割愛させて頂き、ちょっとしたプログラマ話(?)をしたいと思います。 私はプログラミングを職業としているいわゆる"プログラマ"ではありません。ミクシィに新卒入社した2009年からしばらくは営業マンでしたし、その後も今に至るまでサービスディレクターとして勤めてきました。少しさかのぼって、小学校の頃は当時流行っていたGW-BASICでmud gameなどを作ってみたり、大
半年間休職してプログラミングの勉強をした - ぼっち勉強会
目次 概要 この記事の目的 なぜ勉強するのか なぜ休職したのか(働きながらではダメなのか) どのようにして休職したか 金銭面の問題 勉強を継続するために気をつけたこと どのくらい勉強したか 何を勉強したか 反省 まとめ 概要 5月に休職しました。 休職開始から今日まで主にプログラミングの勉強をしていました。 11月から仕事復帰します。 この記事の目的 私が休職して勉強することを決めるとき、経験談を参考にしようと思い似たような方がいないか調べました。 しかし、私のニーズに合う情報はほとんど見つかりませんでした。 私と同じように休職勉強を考えている方にとって、少しでも参考になればいいなと思い書きます。 なぜ勉強するのか 私は業務ならば並以上の働きをしていると思っています。 社交辞令もあるでしょうが、社内・顧客ともに良い評価を頂いています。 一方で、経歴を増すごとに自分の中で技術力に対する不安が
mixiの新人研修トレーニングが非常にわかりやすくて実践的すぎる - Android Javascript iOS
mixiは新人研修用のトレーニングをgithubに公開しています。 公開していることは知っていたけれど、いざみてみると… とってもわかりやすく実践的！！！ 普通に参考書で勉強するよりも企業が公開しているものだから、より実践的という感じもします。 自分はこのAndroidTrainingをやっているのですが、最後に課題もあり、到達度や理解度もすごく把握できていい感じです。 READMEもかなり充実しており、一通りを学べるように工夫されています。 mixiに入社した方がこれを一通りやったと思うと、大変な印象ですが…だからこそやったときに達成感がありそうです。 開発環境の構築から書かれているので、ほとんどつまづくことはありません。 かなり詳しくわかりやすく書かれている印象を受けました。 ちょっと初めて学習するには、難しい箇所もありますが適宜ぐぐって補えばよいでしょう。 ・AndroidTrain
ソフトウェアエンジニアの成長カーブ（再掲載）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事
lightline.vim作りました - プラグインの直交性について - プログラムモグモグ
lightline.vimというVimプラグインを作りました。statuslineをなんかかっこよくしてくれるやつです。 https://github.com/itchyny/lightline.vim からインストールできます。 デフォルト (powerlineと同じ配色) wombat solarized landscape どうしてこれを作ったのかということを話すには、vim-powerlineとの出会いまで遡らなくてはなりません。 vim-powerlineとの出会い vim-powerlineとの出会いは約一年前になります。それ以前から気になってはいましたが、フォントにパッチを当てるのが面倒でためらっていました。しかし、重い腰を上げてインストールしてみました。 vim-powerlineがすごい - プログラムモグモグ インストールしてすぐ感じたことは、配色が気に入らないことでし
プログラマは金魚鉢で泳ぐ - ふたつの教室
いやー、暑いっすね。こうも暑いと仕事の合間にちょっとひと泳ぎしたくなるって事でエクストリーム フィッシュボウルやってみるかーと思い、チームメンバー10人くらいで試してみました。 エクストリーム フィッシュボウルって何かというと、もともとはグループワークの手法で、数人が輪になってディスカッションしてるのを囲むように数人が観察する「フィッシュボウル」というのがあって、それをベースに考えられたものだと思います。(たぶん) で、エクストリーム フィッシュボウルではペアプロをしてる2人をみんなで観察するのですが、観察するだけじゃなくて、質問したり野次を飛ばしたり、実装するメンバーを交代したりしながら開発する手法です。あまり本とかでは見かけないですが、勉強会などで時折行われていたりします。 詳しくはainameさんの説明資料をどうぞ。 extream fish bowl チートシート(Gist) ちな
もしぼくが採用するなら - ローファイ日記
今後役立つ日も来るかもしれないのでメモしておく。Rubyist寄り。 CSに全く興味がない人はきつい 計算機に関する学科を出ていなければ門戸を開かないと言うのは、人不足の現実から言っても厳しいだろうが、我々の用いる道具に関する最低限の足腰は欲しい。 エラストテネスの篩を説明できるとか クイックソートの計算量のオーダは何で、それはなぜか説明できるとか サブネットマスクとは何かを説明できるとか 簡単な帳票を見せて、それをすらすら正規化できるとか 別に「たまたま知らない」とかはあり得るんだが、ポロポロ欠けていると、それまでの勉強の仕方を疑わざるを得ない感じがする。 とはいえ、Rubyistならウェッブ系と言うかサーバ寄りだろうからRDBやネットワークの知識はある場合が多い気もする（経験上身に付きやすいですよね）。でも、ぼくも割とアルゴリズムを勉強してるとかは大事だと思う。単純にいろいろな技術的ド
[プログラミング]よいコードを書くために - logiqboard
コードをたくさん読んでいると、よくできていて参考にしたくなるコードや、身の毛もよだつクソコードなど、色んなコードに出会う。 自分一人で書いていた頃は、コードの良し悪しは全て自分にはね返ってきていたのだが、チームを組むとそうはいかない。 人の書いたコードで苦しむこともあれば、自分の書いたコードで人を苦しめることもある。 そんなことにならないよう、少しでも良いコードを書くために意識するべきことをまとめてみた。 読むのに苦労しないコードを書く 書かれたコードは、それが使われ続ける限り、何度も読まれる。 読む人は自分かもしれないし、他のチームメンバーかもしれない。別の会社の顔も知らない人かもしれない。 そんな人たちでもスラスラ読み解け、理解できるコードは、きっと良いコードだ。 冗長さを制御する 大体の悪いコードは長い。どんなに素晴らしい設計がされていても、長いと読む気力が失せる。コードは短いに越し
![[プログラミング]よいコードを書くために - logiqboard](https://cdn-ak-scissors.b.st-hatena.com/image/square/824a64f5ea8b1fa29b6b1ff45aabef6b5568bc85/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127144886642%2F17680117127144886906%2F1558210211)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
