SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
コードレビュー,慣れるとできるけど,いきなりdiffを渡されて,どうぞ見てくださいと言われてもよくわからないと思う. やりましょうというのはいいけど,ただむやみに読んでもうまくいかない.変更がある程度大きくなるとdiffだけ見てもよくわからないので,いろいろ見ることになる. 僕はいつも以下のようなことを無意識にやってて,うまくいってる気がしてる.GitHubのPull Requestの仕組みを使ってる前提で. Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て,テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく.あとで書き直されるかもしれないので,まだコメントしない 全コミット見終わったらFiles
最初は誰しもがファッ!?となるんですよねロガーって。 いずれtree-tipsで公開しようと思っている、solrのプロジェクトを今作っています。mavenでjarを管理している訳ですが・・ なんだこのロガーの数は!! commons-logging、log4j、slf4j-api、jcl-over-slf4j、logback-classic・・・・、こいつら一体何が違うんだ!どう使い分けるんだ!そもそも必要なのか!?となりました。 昔はcommons-logging+log4jというのがトレンドだった訳ですが、今はslf4j+logbackがトレンドになり、jdkも1.4から1.7になり、これらトレンドが推移する過程で、いろいろなjarが旧式に依存してしまい、旧式依存を解決するためにアダプタが登場し始め、mavenでjarを収集すると大抵両方入ってしまい、カオスになっているのです。 特にs
オブジェクト指向の基本亀仙流やつ鶴仙流など、世の中にはいくつかの流派(=クラス)があり、それぞれの流派にかめはめ波やどどん波、舞空術などの技(メソッド)がいくつかあります。 実際に流派にある技を使う場合、技を覚えているZ戦士(インスタンス)が必要になります。 例)亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す goku = new KamesenRyu("goku"); goku.shootKamehameha(teki); Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます(継承)。 また悟空とクリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります。 クラスはセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。 例)セルを作りましょう。 class Cell extends Goku,Ve
0-1. 前書き この世にはたくさんのプログラミング言語が存在します。Wikiepdiaのプログラミング言語一覧を見ると、実に200個以上というわけの分からない数の言語が並んでいたりします。 【参考URL】プログラミング言語一覧 - Wikipedia http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%... 200の中にはほとんど使われてない言語も混じってるので、実際に仕事でざくざく使われている言語は20とか30とかそういうオーダーなのですが、それでも1人の人間が把握するにはちょっと多過ぎる数です。 本記事では、そうした有り余るプログラミング言語の海の中で「どれを勉強したらいいの?」とか「どれを採用するのが適切?」という悩みをお持ちの方が「よし、この言語に決めた!」と自信を持って決断できるように背中を押すことを目的として書か
設計の終焉? (原題: Is Design Dead?) マーチン・ファウラー チーフサイエンティスト , ThoughtWorks エクストリーム・プログラミング(XP) をかじってみて、多くの人がこう感じ ただろう。XP は「ソフトウェア設計など消え失せろ」と言っているのではな いか、と。というのも XP では、多くの設計作業が 「料金前払いのデカい設 計("Big Up Front Design"」などとからかわれているばかりか、UML、柔軟な フレームワーク、そしてパターンまでもを含む設計技法が、ぞんざいな扱い を受けているか、完全に無視されているからだ。 実際には、XP にもたくさんの設計作業が含まれている。しかしそれを、既存 の設計プロセスとは違うやり方で行っているのだ。「進化的設計」という考え 方がある。XP はこの考え方を、「進化」を実行可能な設計戦略へとに変換す るプラク
2014年版はこちら => http://d.hatena.ne.jp/JavaBlack/20140420/p1 「見習いプログラマが読んでも、ほとんど無意味な10冊」http://d.hatena.ne.jp/JavaBlack/20101124/p1 「プログラマーになるには」http://d.hatena.ne.jp/JavaBlack/20101128/p1 「気合いでやり抜く努力型」http://d.hatena.ne.jp/JavaBlack/20101201/p1 の関係で,あくまで一例として.言語や分野が異なれば,お勧め本も変わってくるので注意.*1 プログラミング言語Java (The Java Series) 作者: ケン・アーノルド,ジェームズゴスリン,デビッドホームズ,柴田芳樹出版社/メーカー: ピアソンエデュケーション発売日: 2007/04メディア: 単行本購
この記事は、http://d.hatena.ne.jp/higayasuo/20090612/1244772658 の「Ctrl+1とCtrl+Spaceうんぬん」の話にインスパイアされて書いた。Eclipse可愛いよ。Eclipse。 記事長いから、さくっと読み飛ばして、アニメーションgifがあるところから読んでも十分訳にたつと思う。 あと、新人さんとかに写経させるのもいいかも。というか、半分ぐらいうちの新人に勉強のためと思って書いたから。で、実際に写経させて役にたった。 Java は Eclipse などの IDE も含めて言語というか、環境というか…だと僕は思ってる。Commons, Maven なども含めたい(まぁ、そのあたりは、CPANも含めてperlだろ。とか、これは否定する人だらけだろうけど、Rails=rubyということを言う人もいるよね)。 少なくとも僕は、Eclipse
2010-11-24 05:56:00 GMT 某所で『プログラマが読むべき10冊』というのが公開されてましたが、 どうみても中身が重いし、バックグラウンドの知識が必要なものが多いと感じたので、 即、血となり肉となる本を独断と偏見でまとめてみました。 ジャンルごとの順番です。どれも読むべきだと思うので敢えて順番はつけません。
このドメインを購入する。 gkbr.me 2018 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware(仮想化マシン)を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
Debian Project/Google ソフトウェアエンジニア鵜飼文敏さんの講演動画を見たのでまとめ。 内容は、フリーソフトウェア、オープンソフトウェアのハッカー、Google内のハッカーがどのようにソフトウェアを作っているか。 少し前の講演だけど、ハッカーを目指す上で非常に参考になった。 ハッカーの特徴 ハッカーとは Hacker ethic ハッカーのソフトウェアの作り方 ハッカーの開発スタイル 手順 要求仕様 設計 実装 テスト デバッグ チューニング ハッカーに近づくには 必要な知識 知識の習得の仕方 ハッカーと仕事をするときの問題点 その他に紹介されていた書籍 感想 参考 ハッカーの特徴 普通の人をはるかに上回る高い生産性 高品質のソフトウェアを作りだす ハッカーとは ハッカーズ大辞典によると、 プログラム可能なシステムの細かい部分を探ったり、その機能を拡張する方法を探求した
それは、リチャード・ストールマン著「フリーソフトウェアと自由な社会」以外にはない。なぜなら、何か道を定めるとき最も重要なのは倫理観だからだ。 社会は欺瞞に満ちている。企業は自社の利益にとって都合の良いことばかりを宣伝し、政府もそのような企業によって動かされ、市民は何が本当に大切なことなのか、即ち倫理を忘れがちである。リチャード・ストールマンの素晴らしいところのひとつに、倫理的な洞察力に優れているということが挙げられる。 倫理を学び、ソフトウェアがどのように社会に貢献するかを知る。それはこれから社会人になろうという人たちにとって、大きな道しるべになろう。リチャード・ストールマンが目指す社会は次のようなものだ。(第2章「GNU宣言」より抜粋。最後の部分。) 長期的には、プログラムをフリーにすることは、飢餓のない世界、つまりすべての人がただ生活するだけのために必死に働かなくても済む世界に向かって
以前見つけた資料。そういやそんなんあったなと久々に検索して探すのに少し手間取ったのでメモ 言語の比較対応で文法覚えられそうなんで便利じゃないかなと 参照: Big Script: PHP, Perl, Python, Ruby, Smalltalk http://hyperpolyglot.wikidot.com/scripting Small Script: Bash, Tcl, Lua, Javascript, IO http://hyperpolyglot.wikidot.com/small Platform: C, C++, Objective C, Java, C# http://hyperpolyglot.wikidot.com/platform Lisp: Common Lisp, Scheme, Clojure, Emacs Lisp http://hyperpolyglo
「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか? 日本語の文字コードは大きく以下の2つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング(文字符号化方式)」の事を指す。 文字符号化方式 文字集合って? 読んでそのまんま”文字の種類の集まり”。「キャラ
3. ThoughtWorksアンソロジー ThoughtWorks社コンサルタント ● の 骨太なエッセイ集 様々な ジャンルを収録 ● DSL、プログラミング、設計、 マネジメント、ビルド、デプロイ、テス ト... オライリーさんブースで ● 絶賛販売中! 3
このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く