コード作成やデータ編集作業など、マイナーだけどすこぶる便利なChromeアプリを一挙まとめ | ライフハッカー・ジャパン
最近、めまぐるしい成長っぷりを見せているChromeアプリストアの「オフラインアプリ」たちですが、残念なことにその多くが知名度を得られていない状態になっています。そこで今回は、米Lifehackerお気に入りの知られざるアプリたちをいくつか紹介してみたいと思います。 Googleはここ最近、Chromeウェブストアにオフラインアプリを数多く投入してきています。オフラインアプリとは、PCにインストールしたアプリさながらに、Chormeブラウザ内で使えるアプリのこと。Chromeブラウザがインストールされているパソコンであれば使えるので、借り物のノートPCや容量が少ないPCで作業する際にもかなり便利です。 全てのアプリがオフライン作業に対応しているわけではありませんが、オフライン使用が可能なものも段々と増えてきています。つまり、大量の容量を必要とするデスクトップソフトウェアの代替として、オフラ
プログラマーは年を重ねてもスキルを向上させ続けていることが研究で判明
By iLikeSpoons 「年輩のプログラマーはテクノロジーの急速な変化についていけず、ソフトウェア開発から外れてしまう」という考え方が存在しますが、ノースカロライナ州立大学の研究によって、新しいソフトウェア・プラットフォームにおいても年輩プログラマーは若い同僚よりも知識があり、プログラミングのスキルは進歩し続けていることがわかりました。 NC State News :: NC State News and Information » Older Is Wiser: Study Shows Software Developers’ Skills Improve Over Time http://news.ncsu.edu/releases/wms-murphyhill-age-2013/ 研究者たちはプログラミング技術に関するナレッジコミュニティであるStack Overflowで8万
第18回 プロジェクトにおけるアーキテクトの役割 | gihyo.jp
アジャイルな開発でデスマーチは回避できるのか この業界には「デスマーチ」という言葉がある。現実的ではない開発スケジュールを設定してエンジニアに過酷な労働を強い、その結果生産されるコードの品質が落ち、次々に発生するバグのためにますます過酷な状態に陥るプロジェクトのことを指す。 デスマーチの根本の原因は、プロジェクトマネジメントにある。現実的ではないスケジューリング、エンジニアの生産効率への過信、過酷な労働環境、非効率な開発環境、ラストスパート型の開発スタイル、などである。 特に日本のIT企業における「元請けが受注、実際の開発は下請け」というゼネコンウォーターフォール型のプロジェクトにおいて、実際にコードを書かないアーキテクトが机上で設計をするという悪習慣がある。これが、設計時（もしくは計画時）の見積りと実際の開発期間に大きなズレを生じさせ、下請け企業に過酷な労働環境を強いる原因の一つにもなっ
「動的言語」の本当の意味の分からない半可通は静的型付言語をつかえ
プロダクトマネージャーの親父がとおりますよ。 最近、型不要とか言っている半可通がいるけど それを書いている人より、それを見て型不要とかを真に受ける連中のほうが心配なんだよね。 とりあえず99％の庶民は静的型付言語を使ったほうがいいよ。 昔とくらべて、使える敷居は低くなってきているけど、実際に きちんとした教育を受けていない半可通が、動的言語がきちんと 使えこなせるわけないから。 一般庶民は コンパイル時にきちんと型エラーにしてくれる「TypeSafe」な言語を使ったほうが幸せだし 遅延評価なんかの動作がきちんと理解できない、職業プログラマ（IT土方）は多いんだよ。 一般庶民がそれなりに、一定品質を確保するために、「TypeSafe」な言語が必要なの。 教養として、動的言語を勉強するのはいいよ。 だけど、普通の仕事に使うのはやめとけ。ろくな品質にならないから。
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。 船底の穴からの浸水を必死でかき出しながら、どうにか進んで行く。そういう航海だ。 船のどこにどれだけ浸水箇所があるのかは分からない。 ある穴を塞ごうと船底に板を打ち付けたら、 それによって別の場所に新しい穴を空けてしまったりする。 船の構造はあまりに複雑で、膨大な部品の間にどんな依存関係や相互作用があるのか、 誰も完全には把握していない。 それは、はるか昔に組み立てられた太古の船で、 構造把握の手掛かりは、代々伝わる不十分で不正確な古文書だけなのだ。 新任の船員は、出た水に対してとにかく手当たり次第に対処した。 どんな物でも使い、徹夜で穴を塞いで回った。 ひたすら大きな声で号令を出し、 いかに早く穴を塞ぐかが、船員の間で競われた。 何人もの船員が過労と心労で倒れ、 航跡には水葬者が点々と残された。 船員たちが経験を積
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
非エンジニアに無念コードがなぜダメなのかを説明するメタファー - Yamashiro0217の日記
非エンジニアに無念コードがなぜダメなのかを説明するメタファーを考えてみた。 目的は、無念コード・設計・環境・フローがあると、 いかに生産性が落ち、ビジネスがうまくいかないか、 プログラマーの心が病むかを、 なるべくエンジニアリングの用語を使わないで説明すること。 他にいいメタファーあったら、ブクマやらコメントやら、ブログ別書くなどして、 世界を幸せにしてもらいたい。 メタファー エンジニアリングとは部屋の掃除と一緒である ストーリー導入 あなたは、ある日、引越しを決意しシェアハウスに引越しました。 引越した先のシェアハウスのリビングは、 それはもう汚い。 散らかり放題、生ゴミ、壁の汚れ。 さぁ。どうしましょう。 さらに引っ越すという手段もありますが、 あなたは、リビングの掃除を試みるのでした。 ストーリー2 片付けをしていたある日、あなたは、 「リビングの中に、俺の鍵（機能や、コードなど）
プロとしての行為 Act as Proffesional
Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応
スマホアプリでプロトタイプが必要なたった一つの理由 | DevelopersIO
こんにちは！おおはしりきたけです。弊社ではFlexの開発をやっていたころからUIプロトタイピングで開発することが多く。特に最近のスマホ開発ではUIプロトタイピングが必須と言っても過言ではありません。 はじめに 皆さんは、プロジェクトを進めていく上で、要求を洗い出す、要件を整理する、ワイヤーフレームを作る、設計書を書く、ビジュアルデザインを作るといった作業をやることが多いと思います。こういった作業というのは、コミュニーケーションの手段であり、プロダクトやサービスのゴールに向けて成功の確率を高めてくための作業だと思っております。クラスメソッドは、クライアント側の開発が多く、ここ数年スマホ開発に携わっていますが、スマホ開発では初期段階でも「動くプロトタイプ」が必要だと体感しております。その理由を書かせていただきます。 結論 結論から説明させて頂きます。スマホアプリでUIプロトタイプを作るたった一
継続開発のススメ 2012-06 版 - Twisted Mind
変更履歴 2012-06-24 ドキュメントの所に *diag シリーズについて追記 概要 開発があればリリースがあり、リリースが終われば、メンテナンスがあり、さらに開発があります。プロダクトが EOSL (End Of Service Life) を迎えるまではこれを続ける必要があります。 去年の 8 月に「継続開発のススメ」というので、やっていることをまとめたのですが約 1 年経ってもう少し細かくまとめて見ようと思いました。基本的には自分がいる環境を前提に書いてます。 継続開発のススメ http://d.hatena.ne.jp/Voluntas/20110823/1314036482 開発スタイルは常に変化し続けていくべきだと思っています。これだ、というのを作らないのが一番良い開発スタイルでは無いかなと。 脳内を書き出しているので、日本語がおかしい上に一貫性が無いと思います ...
自分の仕事を無断で中国に“アウトソーシング”していた従業員──Verizonが事例として紹介
会社で最優秀と見なされていたソフトウェア開発担当者が、実は自分の仕事を中国企業に丸投げしていたことが、VPNのログ調査で発覚した──。米通信大手のVerizonが1月14日（現地時間）、2012年のケーススタディのこぼれ話としてこんなエピソードを紹介した。同社は企業向けにITコミュニケーションサービスを提供している。 米国のある重要インフラ企業に勤めていたこの開発者──Verizonは仮にボブとしている──は長年にわたって、自分の仕事を中国瀋陽市にあるコンサルティング企業に低価格でアウトソーシングし、自分は毎日会社に出勤して動画閲覧やFacebookで時間をつぶしていた。皮肉なことに、ボブの人事評価は非常に高く、この会社の最優秀開発者として10万ドル以上の年俸を得ていた。 ボブの所業は、Verizonの顧客であるこの企業が、VPNのログに不審な点があるとして調査を依頼してきたことから発覚し
アジャイルサムライとは大きく異なるソニックガーデンの見積りと計画作り - give IT a try
はじめに アジャイル開発に興味を持っている人に取っては「まだ読んでなかったの？」といった感じかもしれませんが、先日書籍「アジャイルサムライ」を借りたので、ざっくりと読んでみました。 今回のエントリは読んでみた感想に加えて、ソニックガーデンでの開発スタイルとの比較をしてみたいと思います。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る とりあえず最初から読んでみた 1章の内容はアジャイル開発の基礎知識が中心で、読みながら「うん、まあそうだよねえ」と思いました。 14ページの挿絵にある「やり方がたった1つなんてことはないんだ！」「君自身が編み出
Chromeのリモートデバッグ機能がすごい！ - Hacking My Way 〜 itogのhack日記
ここの動画で紹介されているリモートデバッグがかなり強力なツールなので紹介します。 事前準備 開発マシン側にadbというツール＆Android端末のUSBデバッグを有効にする必要があります。 開発してる人なら説明いらないので省略。 リモートデバッグを有効にする Android端末と開発マシンをUSBで接続して、端末が認識されていることを確認して下さい。 開発マシンのターミナルで以下コマンドを打ちます。 $ adb forward tcp:9222 localabstract:chrome_devtools_remote Android端末のChrome for Androidでメニューから 設定→デベロッパーツール→USBウェブでバッグを有効化にチェック 開発マシンのブラウザで下記URLにアクセスします。 localhost:9222 すると、Chrome for Androidのタブで開い
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ キーマンズネットは、IT担当者を対象にしたアンケート結果として「テスト自動化ツールの導入状況」を公開しました。 それによると、導入済みは全体の8.5％（「既に導入済みである（追加リプレイスなし）」7.5％と「既に導入済みである（追加リプレイスあり）」の1.0％の合計）で、導入を検討しているが4.8％。今後も導入しないするグループは86.7％（「必要性を感じているが導入を検討していない」の38.6％と、「必要性を感じない」の48.1％の合計）」になりました。 グラフを見ると従業員規模1001名以上では導入済みが約15％である一方、100名以下では1.8％であり、従業員規模によって大きな違いがあることが分かります。 対象言語はJavaがトップ、目的は品質の向上、工数削減など すでにテスト
「どうしましたか？」「お腹が痛いんですけど…」「もっと詳しくおしえてください」「えっ、お腹が痛いだけですけど」「それでは診断できません」 - uzullaがブログ
医者「今日はどうしましたか？」 患者「今は落ち着いてるんですが、最近どうも腹痛がひどくて…」 医者「もうちょっと具体的に言ってください」 患者「そうですね、なんとなくシクシクと…」 医者「なんとなくとかいわれても困りますね、もっと具体的に現象を教えてください」 患者「えっ」 医者「たとえば、脇腹に針をさしたようにいたい、とか。みぞおちに重い鈍痛があるとか、具体的に」 患者「ううん、そうですね…みぞおちが痛かったかも…」 医者「かも！？」 患者「みぞおちがいたいです！刺すように！」 医者「みぞおちがいたい、刺すように、なるほど（カリカリ」 患者「どうなんでしょう…胃炎とか…」 医者「素人が症状を断定しないでください」 患者「すみません…」 医者「今の症状はわかりましたから、どこで、いつ、どうやったら腹痛になったか、状況を詳しく、順番に教えてください。まず痛くなったのは何時何分何秒で、その何分
テストというのは、ソースコードの冗長化だと思う - きしだのHatena
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
「ウェブサービスを一人で作れるなんて嘘だろ！実際大変じゃねーか！」 - uzullaがブログ
ワナビーのみなさんこんにちは、ワナビーのuzullaです。 昨日の記事を読んで、このタイトル通りのことを思った方、俺も同感です。 ワナビーではない皆様、ご機嫌麗しゅうございます。 本記事全くお役には立ちません。後半の割とゲスいサービスつくってください。 前の記事が久々に100ブクマとれてしまい*1、調子に乗って書いた、真の蛇足記事がこれです。 俺が蛇足記事だ！ 「つくるぞー！」＞「できた～」＞「人こない…」＞「サーバー落とす」 参考：http://uzulla.hateblo.jp/entry/2012/03/15/170632 上を分解すると ・作るのが大変 ・宣伝するのが大変 ・回すのが大変 ・クローズするのが辛い 作るのが大変なのは、(技術|腕|スキル)の所為？ これ系は解決する方法がネットにもうゴマンとあるし、割と努力次第でどうにかなるので、まあどうでもいい感ある。 ただ、アリガチ
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
