統計的なインデントチェッカー - hitode909の日記
ソースコードを入れると統計的にインデントの変な箇所を見つけて教えてくれる便利ツールを作った． hitode909/auto_indent · GitHub 昨日，統計的にインデントするのを作ったけど，実用には耐えないくらいの精度だった．それの続き．昨日の読んでない人はまずこれを読んでください． 統計的にインデントするやつ - hitode909の日記 昨日のやつだと，もとのインデントを無視してプログラム全体をフォーマットしようとするので，失敗が許されない． 変なインデントを探して教えてくれるくらいなら，出てきたレポートを人が見て直すかどうか判断できるので，ちょっとましだろうと思った． あらかじめソースコードをいろいろ与えて，こういうデータを作っておく． ;,s,{"0":96,"-4":1} ;,},{"-4":754,"-8":15,"-15":1,"-2":4,"-9":1,"-12"
「壊れてねぇなら直すな」という発想は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年の発言が人口に膾炙したもののよ
脆弱性パッチあてろよとかフレームワークのバージョンアップしろよとか - ikeike443のブログ
http://www.jins-jp.com/info.html これ、大変ですね。 保守契約がどうなってたのか、当初見積りにフレームワークの脆弱性パッチ適用作業費用は入ってたのか、顧客はそもそもこう言うことが起こり得ることを予見していたのか。 営業から保守費用が高すぎるって言われて仕方なくこういうところを削った見積り書いて営業に渡して、顧客とちゃんと確認してねみたいなこと伝えて、営業は本質的なことは理解してないから顧客には説明せず、顧客はベンダーに全て任せてるつもりだから気にもせずみたいな。 この手の作業って基本は大した工数にならないはずなんだけど、場合によってはパッチじゃすまずフレームワークのバージョンアップしないといけなくなって、つまるところアプリケーションコードの書き換えが発生したりなんかして、工数跳ね上がっちゃうリスクあるので、保守費用としてはある程度多めに出さないといけないし、
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
ソフトウェア工学は失敗している - きしだのHatena
特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
続・技術的負債の把握と改善を促すために - mixi engineer blog
こんにちは, 先日Kansai.pmで発表させて頂いたgoccyこと五嶋＠たんぽぽグループです. 今回は, 前回紹介した技術的負債の把握と改善を促すためにの続編として, 僕が作ったPerl5コードのコピペ検出器について紹介させて頂きます. はじめに 今やPerl, Ruby等さまざまな言語で, 便利なライブラリ群やフレームワークを利用できる時代になりました. これらを使うことでソフトウェアの開発コストは格段に下がり, より素早く開発することができるようになっています. しかし, 当初予定されていた機能を実装して, 「よしできたから終わり！」というわけにもいきません. 何か物を生み出せば, 必ずそれを保守・運用するコストが発生します. 開発することが便利になった今, 開発物を保守・運用することを支援するツールも求められています. ですが, 保守や運用, とりわけ保守に関して支援するツールはそ
Google Chrome Extensions (拡張機能)の作り方
唐突にGoogle Chromeのエクステンション（拡張機能）が作ってみたくなりました。 作り方を調べたときの過程をメモしておきます。 参考サイト エクステンションの作り方を解説しているサイトはこちら。 http://code.google.com/chrome/extensions/index.html 一番簡単なチュートリアルを写経してみます。 Tutorial: Getting Started (Hello, World!) http://code.google.com/chrome/extensions/getstarted.html ちなみに、試したときのChromeのバージョンは「4.1.249.1064」です。 チュートリアル まず、作成する拡張機能の設定ファイルやhtmlを保存するフォルダを作成します。 今回は、「C:\chrome_extensions\tutorial」
雑談 - hitode909の日記
使って満足感のある、安心して使える、国産の、高級感のあるソフトウェアを作りたい。そのためには、ソースコードを最高に読みやすくて何の欠点もない状態にしなければならない。 例えば、このサッカーボールはどのようにして作られているのですかって聞いたときに、ブラジルの子供たちを学校にも行かせず労働させて作っていますみたいな感じだと、そういう感じでは縫い目のなめらかさまでこだわれなくて、転がればいいくらいの雰囲気になると思う。 ところで、このソフトウェアは古いよくわからないコードをよくわからないまま適当に書き換えて作りましたって聞くと、心配になると思う。 コードの品質が悪いと新たな機能を追加したり、不具合を修正するのが難しくなる。 コード読んでも、どこを変えれば良いか分からなくて、前に似たようなことをした人の手順を聞いて、その通りに真似して書いて動けば完成みたいになる。 実際どこでどうなって動いている
MY JOB WEND TO VIETNUM? DevSumi ver.
デブサミ2013 14-E-7 Enterprise TED の枠でお話させていただいたプレゼン資料です。 Read less
GitHub時代の開発委託とは？ デブサミでQA@ITの事例の話をします - QA@IT公式ブログ
2013年2月14日と15日の2日間にわたって東京・目黒で開催されるDevelopers Summit 2013（デブサミ2013）の1セッションで、QA@ITの委託開発の話をさせて頂くことになりました。 ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例（仮） 私はこれまでいつも、デブサミは取材記者という立場で見て来ました。記者として取材して、例えば以下の様な記事を書いて来ました。聴衆に混じって講演を聞く側だった私が、まさか話す側に回ることになるとはと、今からドキドキしています。 デベロッパーズ・サミット2008：すばらしいソフトを作るには、カリスマが講演 未来の言語は「APL」？ Rubyのまつもと氏が講演 IIJのRuby対応PaaS「MOGOK」は、どんなサービスか？ さて、デブサミは開発者のイベントですが、私は委託側、つまり受託開発における「お客の声」ということでお話
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（後編）
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（後編） スクラムは、アジャイル開発における方法論の中でもっとも普及している方法論の1つです。スクラムという用語を用い、その考え方を最初に提唱したのは、1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。それが1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによってアジャイル開発の方法論としてのスクラム（アジャイルスクラム）になったわけです。 1月15日に都内で開催されたアジャイル開発をテーマにしたイベント「Scrum Alliance Regional Gathering Tokyo 2013」では、2
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（前編）
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（前編） スクラムは、アジャイル開発における方法論の中でもっとも普及している方法論の1つです。スクラムという用語を用い、その考え方を最初に提唱したのは、1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。それが1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによってアジャイル開発の方法論としてのスクラム（アジャイルスクラム）になったわけです。 野中氏は知識創造理論によって知られており、ウォールストリートジャーナルによる、「もっとも影響力のある思想家リスト」の20位にランクされています。 1月15日に都内で
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPCで「はてなブログの開発フロー」について話してきました - 大西ブログ
はてなのイマドキの開発フロー - YAPC::Asia Tokyo 2013
Chrome拡張入門
デブサミ2013、講演関連資料まとめ
ニコニコ書籍の作り方
DeNA流Scrumとcommのチームビルディング
僕は会社を良くしたい( ｰ`дｰ´)ｷﾘｯ - Google スライド