命名の話 - その手の平は尻もつかめるさ
命名の話をしました．1時間位でなんとか間に合わせで書いた資料です． よろしくお願いします． 命名の話 from moznion www.slideshare.net あと，例えばメソッド名で"get"と"retrieve"と"fetch"をどう使い分けるか，みたいな話題が出て， 僕あたりは getは単純なゲッター的なものに使う retrieve は DB にアクセスして値を取ってくるものに使う fetch は何らかごちゃごちゃ処理をして (API 叩くとか) 所望の値を取ってくるものに使う という風な使い分けの話をしました．そういったルールが各々の人の中にはあります． ここらへんのルールというのは個人が好き放題やっても無力なので (というかノイズたりえるので) プロジェクトの人間たちが話し合ってすり合わせる必要があります． とは言え，いちいち些細な命名の問題について話し合っていくのはだるい
プログラムを高速化する話
9. 9 最適化について 「細かい効率のことは忘れて、時間の 97% について考え よう。時期尚早な最適化は諸悪の根源だ。それでも残り 3% についても機会を逃すべきではない」 - Donald E. Knuth 「プログラム最適化の第一法則 : 最適化するな。 プログラム最適化の第二法則 ( 上級者限定 ): まだするな。 」 - Michael A. Jackson 11. 11 最適化の対象 主に Intel の Haswell マイクロアーキテクチャ以降を対象 多くのテクニックは他のプロセッサにも応用できます ベース マイクロアーキテクチャ プロセスルール 登場年 Nehalem Nehalem 45nm 2008 〃 Westmere 32nm 2010 Sandy Bridge Sandy Bridge 32nm 2011 〃 Ivy Bridge 22nm 2012 Hasw
新卒採用サイト2023年卒｜リクルート
20分で解説まるわかり！リクルート 忙しい学生のみなさんに、 サクっとすきま時間に見てほしい リクルートの会社説明動画です。 チャプターリスト 00:12 オープニング 02:17 リクルートについて 04:33 リクルートの事業について 08:12 配属職種について 10:37 入社後キャリアパスについて 11:56 成長を促す制度と風土 15:58 新規事業への挑戦 18:20 仕事とプライベートの両立
1万時間の訓練 | プログラマが知るべき97のこと
1万時間の訓練著者: Jon Jagger 「集中的訓練 (Deliberate practice：DP)」という言葉があります。集中的訓練は、ただ課題をこなすだけのものではありません。「課題のための課題」、課題を終わらせるためだけに課題をやっているのだとしたら、それはまったく集中的訓練とは呼べないでしょう。 集中的訓練の目的は、あくまで自らの能力を高めることにあります。いわゆる「スキル」や「テクニック」を身につけることが目的なのです。集中的訓練において重要なのが「反復」です。身につけたい能力をいくつかの小さな要素に分割し、その一つ一つについて反復訓練をし、習熟度を高めていきます。つまり「反復の反復」が必要になる、ということです。ゆっくりと、能力全体の習熟度を望ましいレベルにまで引き上げていきます。集中的訓練の目的は習熟度を上げることであり、個々の課題、作業をこなし、完了することではないの
WIPであろうと、情報共有すると何がいいのか？ - ppworks.jp
口頭で話したことを文字に起こすことについての続編のような記事です。 消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。 口頭で相談したことをesaやqiita:teamにまとめる 口頭でコードレビューしたことをgithubやgitlabのコードレビューのコメントにも書き残す 口頭で話したことをチャットにも書き残す チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す 情報共有すると何がいいのか？ 何がいいか。 暗黙知を減らすことが出来る 当事者に なろうと思えばなれる なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるという
Loci - Programming Language — Loci Programming Language
Loci - Programming Language¶ Version 1.5 is now available! See Releases for more information. Introduction¶ Loci is a multi-paradigm systems programming language. Or, to describe it in a slightly more intuitive way, it’s very similar to, and a close competitor of, C++. It’s a language that aims to not only fix many of the problems that plague C++, but also to introduce whole new paradigms and prog
Dwangoプログラミングコンテストの感想
2016年2月14日、dwangoプログラミングコンテスト2016が行われた。「ドワンゴからの挑戦状」というタイトルもつけられている。 今回の競技プログラミングの参加者は、1月24日に行われた予選を勝ち残った、2016年度新卒予定者から上位20名、一般から上位10名の者である。予選では、以下のような問題が出された。 Welcome to dwangoプログラミングコンテスト - dwangoプログラミングコンテスト | AtCoder この予選が終わった後で、筆者が予選問題を試みた結果が以下である。 本の虫: ドワンゴのプログラミングコンテストをクリアできなかったお話 筆者は、C問題のゲーマーじゃんけんの期待値計算が分からなかったので、バカにでも書けるモンテカルロ法を使い、力技で解こうと試みたが、少数点6桁という圧倒的に高い精度が要求されているため、必要な精度が出ずに敗北した。後に聞くとこ
多くの若きプログラマたちが学ぶべきこと | POSTD
私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン
コードの論理的検証
ソフトウェアに誤りがないことを論理的に検証するための「形式的証明(formal proof)」という手法があります。しかし形式的証明を手作業でやろうとすると、コードそのものを書くより手間がかかり、しかもその際にミスが起きる恐れもあります。自動ツールが使えればそのほうが望ましいのは確かですが、いつもそれが可能とは限りません。ここは間を取って、半形式的証明とでも呼べる方法をお話ししましょう。 まずすべきことは、対象となるコードを全て短いセクション(1行、ファンクションコール1つだけのブロックから10行くらいのブロックまで)に分割することです。そうして短く切った上で、個々のセクションが正しいかどうかをチーム内で話し合うのです。その場合、どのセクションについても、メンバーの中で最も懐疑的な態度の人が正しいと納得すれば、一応「正しい」とみなしていいでしょう。 コードをセクションに分ける際には、まずセ
コードレビュー
コードレビューは一般的に「実施すべきもの」とされています。なぜでしょうか。コードの質を上げ、欠陥を減らすためでしょう。しかし、目的はそれだけとは限りません。 プログラマの中には、コードレビューを毛嫌いする人が多くいます。おそらく過去に、コードレビューでなにか嫌な経験をしたことがあるのでしょう。全コードが社会規定のレビューを担当するのはだいたいアーキテクトやリードデベロッパです。「アーキテクトがすべてをレビューする」というプラクティスです。そうすることが企業の「ソフトウェア開発工程マニュアル」などで規定されていれば、プログラマはその規定にしたがう他ありません。 そのような厳しく堅苦しいレビューが必要な企業も中にはあります。しかし、大半の企業ではそうではありません。どうしても非生産的になってしまうからです。この種のレビューを実施すると、レビューを受けている側は、まるで自分が軍法会議にでもかけら
コードレイアウトの重要性
もう何年も前のことですが、私は以前、COBOLを使ったシステム開発に関わっていたことがあります。そのシステムでは、十分な理由がない限りインデントを変更してはならない、という規則になっていました。誰かが余分なインデントを入れてしまったために、システムに以上が起きたということが以前あったためです。この規則は、適切なコードレイアウトにしないとコードの意味が誤解されやすい場合にも、例外なく守らなければならないことになっていました。その結果実際に誤解を招くことがよくあったので、私達は常に不安に苛まれ、慎重にコードを読んでいました。この規則はプログラマにとって大きな足かせになっていたし、それによるコストも大変なものだったろうと思います。 プログラマは仕事の時間を、実際にコードをタイプすることよりも、コードを探すことと読むことに費やしている、そんな調査結果もあるようです。修正すべき箇所はないか、あるとす
他人よりまず自分を疑う | プログラマが知るべき97のこと
他人よりまず自分を疑う著者: Allan Kelly プログラマというものは(つまりわたしたちは)自分の書いたコードに何か誤りがあるとは、なかなか考えようとしない人種です。現に問題が起きていても、それが自分のせいだと思うことは滅多になく、「きっとコンパイラのせいだろう」などと思ったりします。 しかし実際には、コンパイラやインタプリタ、OS、アプリケーションサーバ、データベース、メモリマネージャなど、システムソフトウェアのバグで問題が発生するということは、極めて稀なのです(ほぼないと言っていいでしょう)。もちろんシステムソフトウェアにもバグはあるものですが、責任を押し付けたがる人が期待するよりは、はるかに少ないと言えます。 私が「本当にコンパイラのバグが問題の原因だった」というけいけんをしたのはたった1度だけで、ループ変数の最適化に関わるバグでした。それよりも、コンパイラあるいはOSのバグの
コーディング規約を自動化する | プログラマが知るべき97のこと
コーディング規約を自動化する著者: Filip van Leanen あなたも見たことがある光景かもしれませんが、新しいプロジェクトが立ち上がる時というのは、みんな「抱負」を持つものです。ああも使用、こうもしよう、と希望に燃えるのです。そういう抱負は、多くの場合ドキュメントにまとめられます。たとえば「このプロジェクトでは、一定の規約に従ってコーディングをする」ということが決定され、その規約がドキュメントにまとめられたりするのです。キックオフミーティングでは、プロジェクトリーダーがドキュメントの内容を承認し、プロジェクトのメンバーの多く、時には全員が、その規約を守ることに賛成します。しかし、いざプロジェクトが開始されると、こうした最初の抱負は徐々に顧みられなくなっていきます。そしてプロジェクト完了時には、規約など全く無視された無秩序なコードが、なぜそうなったのか誰にも理由がわからないまま、納
分別のある行動 | プログラマが知るべき97のこと
分別のある行動著者: Seb Rose 何をするにせよ、常に分別を忘れてはならない。自分のしたことがどういう結果を生むか、よく考えるのだ。 作者不明どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者のほうが魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結果、修正が不可能になってしまうことも多いのです。この
エッセイ一覧 | プログラマが知るべき97のこと
[出典] プログラマが知るべき97のこと 当サイトはオライリー・ジャパンによる公式なサイトではありません。 個々のエッセイは「CC-by-3.0-US」によってライセンスされています。
多種多様な基準から見るプログラマの市場価値 | POSTD
私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ
コミュニケーションが苦手な人間がチーム開発にのぞむためには - ppworks.jp
私はコミュニケーションが下手だし、何より苦手意識がある。そして、チーム開発にはコミュニケーション能力が必須であると感じている。つまりあるがままの自分のままでチーム開発をするのは矛盾がある。 私の理想とするコミュニケーションの達人は以下の3点を満たしている（そもそもこれが間違っている可能性が十分にある）。 論理的に話を組み立ててわかりやすく話せる 別け隔てなく笑顔で接することが出来る 空気を読める この3点のうち、私が出来るのはなんとか空気を読むという点だけであり、それで他をカバーする以外に作戦はないと思っている。 論理的に話を組み立ててわかりやすく話せる 話していて、「あーこのひとは地頭がいいなー、話の組み立て方が自然と論理的になるなあ」と感じる人が周りにいてどうしたらこうなれるかというのをずっと考えてきた。優秀なプログラマーは基本的にこの、論理的に話を組み立てるというのが圧倒的にうまい。
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reddit - Dive into anything
http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E9%96%A2%E6%95%B0%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%93%E3%81%A8%E3%81%AE%E9%87%8D%E8%A6%81%E6%80