最近よく目にする「フルスタックエンジニア」とは何だろうか？
このところ海外（おもに米国）のスタートアップで、「full stack engineer」の求人広告を以前より多く見かけるようになりました。フルスタックエンジニア、つまりインフラからミドルウェア、モバイル、デザインまで、あるいは設計からプログラミング、デプロイまで、何でもこなせるエンジニアを募集している、ということのようです。 例えば、このPublickeyでも導入しているコメントシステムの開発元であるDisqusは現在、「Full-stack Web Engineer」を募集しています。 「What We're Looking For」の項目では、5年以上のエンジニア経験とチームリーダーの経験などを求めた上で、技術的には次のような要件を並べています。 Very experienced with web application deployment and software design
Visualizing git blame
Git には git blame というコマンドがあり(他のツールでも同様の機能は提供されている)、これを使うことでソースコードのどこを書いたのが誰か、という情報がline-by-lineで取得できる。この情報は行単位なので一次元の情報だけれど、適切な空間充填曲線に乗せることで二次元にマッピングできて、それに適当に作者ごとに色をつけるということをやってみると色々楽しい。そのスクリプトはひじょうにstraight-forwardな記述だとこういった感じになる。上の絵はruby 1.8.7に対する実行結果で、ChangeLogとかのあきらかに面白くないファイルは除外してあるからまあ、そのままの結果ではないけれど、これを見ると色々な思いが去来する。 Ruby 1.8.7 は多数の開発者が手を入れており、少数の支配的な貢献者といったような存在をみいだすことができないしかしながら、全体がのっぺりと灰
「壊れてねぇなら直すな」という発想はRailsにはないのかも - QA@IT公式ブログ
QA@ITはRuby on Railsで構築・運用しています。で、そろそろRailsの新メジャーバージョン、Rails4のリリースが近づいているようです（と、聞くようになってずいぶん経ちますが）。いろいろと新機能がありますが、GitHubを見ていて1つ驚いたことがあります。Ruby on Railsの生みの親のDHH（David Heinemeier Hanssonさん）が、メジャーバージョンアップとなるRails4に向けて行ったこのコミットに唐突感があったのです。よく使われるAPIの名前を、こんなに簡単に変えちゃうんだという軽い驚きです。 「壊れてねぇなら直すな」（If it ain’t broken, don’t fix it.）という有名な言葉があります。米国のジミー・カーター大統領時代の行政管理予算庁長官だったトーマス・バートラム・ランス氏の1977年の発言が人口に膾炙したもののよ
コードクローンが良いか悪いか、CCFinderを語らないところに、この事件の面白さがある - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） みずほ証券の話がまだ話題ってことの続き この記事 ［論点3］どんな開発手法を適用すべきか http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465909/ （以下太字は、上記記事より引用） 最近のブログなどの論点は２つのようだ。 ・詳細設計書の修正に関して ・コードクローンに関して 前に「詳細設計書の修正に関して」を論じた。 なので今度は、「コードクローンに関して」について論じる ■この事件の不自然さ この事件の「コードクローンに関して」 ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされて
計算幾何学問題「キュラゲの最小包含円を求めよう」の解説記事です！キーワードは「乱択アルゴリズム」 #ゲーム開発 - CodeIQ Blog
CodeIQ中の人、millionsmileです。 出題者のstakemuraさんによる「計算幾何学」問題の解説記事です。 アクションゲームなどでキャラクターを攻撃するとき、ナイーブに１キャラクターごとに１ピクセル単位で処理していたら、計算時間は大変なことになります。さて、どうやったら物理演算を軽くできるのでしょうか？キーワードは「乱択アルゴリズム」です。 ゲーム開発をしている方は必見の記事です。 =============================== 高速化の秘訣は乱数にあり stakemuraです。 先月、「キュラゲの最小包含円を求めよう」というタイトルで、CodeIQでは初となる計算幾何学の問題を寄稿させて頂きました。いきなりの難問だったにも関わらず２４名もの方に挑戦して頂き、中には当方が驚かされるような回答もあったりして、達成感を噛み締めている今日この頃です。さて、挑戦者が
EclEmma - JaCoCo Java Code Coverage Library
JaCoCo is a free code coverage library for Java, which has been created by the EclEmma team based on the lessons learned from using and integration existing libraries for many years. Snapshot Builds The master branch of JaCoCo is automatically built and published. Due to the test driven development approach every build is considered fully functional. See change history for latest features and bug
コーディングルール違反と不具合数の関係を調べた研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2008年に"Assessing the value of coding standards: An empirical study"というタイトルの論文がIEEE International Conference on Software Maintenance 2008に掲載されています。 論文のPDFはIEEEの電子図書館のページから入手できますが定期購読していたり、IEEE memberのアカウントが必要になります。本論文と同等の内容のテクニカルレポートが著者のサイトからも閲覧できます（こちら）。 MISRA Cで定義されているコーディング規約の逸脱と不具合数との関連の調査結果を報告しています。対象ソースコードは家電製品用の組込みプログラムのもの。開発中に構成管理システムに蓄積されたソースコード編集履歴からコーディング規約準拠と不具合数の関係を調べて報告しています。 MISRA Cは
技術的負債を管理する
日付2013-5-18(Sat) 書いた人おかざわ (id:yujiorama) 書いた理由技術的負債はいつ読んでも面白いんだけどそろそろ普通に向き合いたくなったので。 技術的負債を管理する 技術的負債は悪いものとみなされている。避けるべきものであり、できるだけ早く支払うべきものなのだ。 あなたもそう思うだろうか？私たちはそうは思わない。最初に技術的負債と財政的負債を比較して、戦略の設計とステークホルダーにおける類似点について驚くべき点があることを説明する。それからコード中の技術的負債を識別するための様々な可能性について一覧にする。それらはきっとあなたが対処しなければならないものだ。 最後にプロジェクトが技術的負債を返済するために取りうるいろんなやり方について述べる。あなたが返済したほうがよいのか、負債を変換するほうがよいのか、ただ注意を払うだけでよいのかを考える時にきっと役に立つだろう。
DI コンテナがコードに出現するのは dependency lookup が行われている兆候
Dependency Injection (DI) コンテナを基盤にしたアーキテクチャを採用している場合に、(プロダクト|テスト)コードに DI コンテナが登場するのは dependency lookup (依存コンポーネントの検索)を行っている兆候と考えることが出来ます(もちろん必要があってコンテナの injection が行われている場合もあります)。 テストに DI コンテナが出現することに気付いたら、 Dependency lookup から Dependency Injection (DI) へのリファクタリングの契機とすることもできるでしょう。 続きを読む
Javaはどのように動くのか～図解でわかるJVMの仕組み 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
CLOC -- Count Lines of Code
cloc is now being developed at https://github.com/AlDanial/cloc Overview [Translations: Belarussian, Bulgarian, Russian, Serbo-Croatian, Slovakian Ukrainian ] cloc counts blank lines, comment lines, and physical lines of source code in many programming languages. Given two versions of a code base, cloc can compute differences in blank, comment, and source lines. It is written entirely in Perl with
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
デザインパターンの自動化
.NETで簡単な例を見てみましょう。 public Person : INotifyPropertyChanged { string firstName, lastName; public event NotifyPropertyChangedEventHandler PropertyChanged; protected void OnPropertyChanged(string propertyName) { if ( this.PropertyChanged != null ) { this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } public string FirstName { get { return this.firstName; } set { this.firstName
汎用的な観点ではなく業務特化の観点でのレビュー実施の効果を予想した研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2013/3/12に「業務観点でのレビューを目指した不具合情報の分析」というタイトルで情報処理学会ソフトウェア工学研究会で発表しました。論文PDFはこちら。（本著作物の著作権は情報処理学会に帰属します。本著作物は著作権者である情報処理学会の許可のもとに掲載するものです。ご利用に当たっては「著作権法」ならびに「情報処理学会倫理綱領」に従うことをお願いいたします。） レビューのコスト削減効果は、レビューで検出して欠陥を修正したときのコストとレビューで見逃して（あるいはレビューを実施せず）レビュー以降のフェーズで欠陥を検出し、修正したときのコストの差です。@IT情報システムマネジメントの記事「レビューを「数」だけで管理しているからコストが膨らむ」で解説しています。 レビューで検出することによってコスト削減につながる欠陥をつきつめると、どのようなものになるでしょうか。おそらく対象ソフトウェアにとっ
ソースコード変更波及解析の8カテゴリ - どのくらいご存知ですか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
変更波及解析は既存のソフトウェアに変更を加えたら、どの場所に影響を与えるかを調べる方法です。影響は本来の意図であるものや本来意図していない副作用も含みます。変更波及解析が不十分だとデグレードする場合があります。 Steffen Lehnert氏のA Review of Software Change Impact Analysisという文献調査をしたテクニカルレポートがここで公開されています。調査対象の文献が182件ある大きめの調査です。網羅性や調査方法に関しても客観的な基準を与え、洗練した上で論文として公開されるのかもしれません。 このテクニカルレポートで紹介されている影響波及解析のカテゴリの一覧は以下のとおりです。10カテゴリのうち9番目は組合せ、10番目は「その他」なので、実質的には8カテゴリあります。どのくらいのカテゴリをご存知ですか？ いずれも完璧とはいかないまでも、変更波及解析
ペア・プログラミング：An Agile Way：オルタナティブ・ブログ
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
アジャイルの「顧客に価値を届ける」の嘘と本当 - mizchi log
酔った勢いでアジャイルについて思うところを書く。 顧客に価値を届けるのは誰か 顧客に届く価値 = 目に見える成果物、という評価は、フロントに近い人間しか評価されなくなる傾向を抱え込む。顧客に価値が届くまでには段階がある。複雑なものほどワークフローが長大になる。お互いの価値を見積もれるのは、小さいチームでお互いの職種について理解がある場合の理想であり、多くの場合理想は理想である。大きなチームほど、フロントに遠い人間は自分の価値を伝えるのが難しい。 難しいことを難しいということ エンジニアが自分の仕事について、エンジニア以外への責任説明を果たそうとすると努力は必要だが、必ずしもそれが伝わるとは限らない。 難しいことを難しいと言えないと、「それってすぐできるんでしょ？」という展開になりがちで、「任せてくれ！」と言えるのはかっこいいが、誰しもがスーパーエンジニアではない。そして見積もりに失敗する。
コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。 優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスとい
読みやすいコードってどんなものか考えてみた -抽象化と名前重要- - tumblr
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
ITエンジニアの実務スキルを見抜ける「CodeIQ」で、コードゴルフ問題を出してみた
はじめに いつもは「マンガで分かるプログラミング用語辞典」でマンガを描いている柳井です。今回は「CodeIQ」という「ITエンジニアのための実務スキル評価サービス」で、プログラミングの問題を出しましたので、その結果報告をしようと思います。 CodeIQ：ITエンジニアのための実務スキル評価サービス まずは、問題に解答いただいた方に、お礼と感謝の意を表しておきます。 解答者と出題者の双方にメリットがある「CodeIQ」 それでは、「CodeIQ」がどういったサイトなのかを紹介します。このサイトには、常時20～30問ほどの、「ITエンジニア向けの問題」が掲載されています。プログラミングでは、Ruby、PHP、Java、JavaScript、SQL、言語問わずといった、各種言語の問題が出ています。またプログラミングだけでなく、レポート作成や、データ分析など、多彩な問題が掲載されています。そしてこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
