Emacsは死んだ - Qiita
Emacs（イーマックス）とは高機能でカスタマイズ性の高いテキストエディタである。スクリーン・エディタとしての人気が高く、特にUNIXのプログラマを中心としたコンピュータ技術者に愛用者が多い。(⇒ http://ja.wikipedia.org/wiki/Emacs) 「Emacsは死んだ」元記事⇒ http://cx4a.org/pub/emacs-is-dead.ja.html 筆者の松山朋洋さんは auto-complete.el の作者です。面白い記事ですので是非ご一読を！ 文書のライセンス この文書はCreative Commons Attribution-Noncommercial-No Derivative Works 3.0のもとでライセンスされています。 -- 松山朋洋 (2010/2/22) 何よりもまず最初に、あまりにも感傷的なタイトルを付けたことについて謝罪しなけれ
ソフトウェアを作るのは、意外と難しい
プログラマ同士で話している時には当たり前の事だけど、非プログラマと話すと意外と共有されてない事に、これがある。 ここ最近、プログラマでない人とソフトウェアを作る、という話が三回あった。 一度はその人の為にツールを作る、という奴。もう一つは私のアプリのデザインを一部変更する、という話で、けれどデザイナがソフトウェアのデザインやった事無い、という奴。もう一つはアプリの素人だけど、アプリのアイデアとかはあるからアプリが書けるようになりたい、という人に話をする、という奴。 ちゃんと作ったのは最初のツールだけで、残り二つは辞退したけれど、どのケースでもソフトウェアを作るというのは結構難しい、という事があまり共有されていない。 私は結構ソフトウェアを作るのは難しいから、XXXみたいな事が必要だ、というような提案をする。 例えば、リモートの開発はかなり困難で、メールのみでソフトウェアの振る舞いの話をしあ
不具合にテストを書いて立ち向かう - t-wadaのブログ
テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時
Spikaを公開して起こった事 - ヨーロッパで働くIT土方社長のブログ
久しぶりにブログを書きます。 10月の最初に弊社のオープンソースプロジェクト Spika をリリースしました。最初の1週間は全く反応が無く、30個近くのブログにプレスリリースを出したのですが、最終的に掲載して頂いたのは、TechWaveさんとMoongiftさんでした。 この期間は全くユーザーの反応が無かったので、かなり落ち込みました。Spika自体は今年に入ってから着手してまして、社員の誰かの稼働が空いた時に、日頃お客さんの要望に答える事を優先して、自分の好きな様にアプリが書けないフラストレーションを解消するプロジェクトとして進めておりました。オープンソースでモバイルメッセンジャーを作ると言うアイデアは僕のアイデアでして、SNSが流行った後にビジネスSNSが流行した流れがあったので、モバイルメッセンジャーでもビジネス利用の流れがあっても良いのでは無いかと思ったのがきっかけでした。ただ、僕
政府専用メールシステム構築へ NHKニュース
政府は、メールを共有できるグーグル社のサービスで、政府の情報が誰でも閲覧できる状態になっていた問題を受けて、外部のサービスを利用しなくても済むよう政府内で情報が共有できる専用のメールシステムを早急に構築する方針を固めました。 この問題は、グーグル社がインターネット上で無料で提供しているメールサービスを通じて、環境省の担当者が送信した国際条約の交渉内容など、政府の情報が誰でも閲覧できる状態になっていたものです。 これを受けて、政府が実態調査を行った結果、１４の機関で外部のメール共有サービスが使われていて、このうち８機関では、誰でも閲覧できる状態にはなっていなかったものの、外部に公表していない情報が含まれていました。 外部のメールサービスを利用した理由について、使用していた職員などは「海外の国際会議に出席した際に、国内の同僚と情報を共有するために使い勝手がよかった」などと話しているということで
アジャイルを学ぶの巻 | いきあたりばったり
アジャイル・・あじゃいる・・agile・・ IT業界に身を置いてると意識せずとも聞こえてくるWord・・ 形容詞なのに、ちまたでは、動詞や名詞として使われがちです・・ そして勤めているSIerではアジャイルは禁止されています。 これまでアジャイルな開発(でも実態はそもそも最初から入札、請負契約というアジャイル風だった…)に手を出しては、もはや顧客の奴隷のようになり、赤字という顛末のPJが多かったからです (｡´Д⊂) ｳﾜｧｧｧﾝ このツイートが身に染みる、そんな状況です。 なのでスキーム変えられないうちは「禁止」という判断は正しい気がします。 最近とても勉強になってるんですが、ウォーターフォールのスキームの一部にアジャイルいれても赤字になるのです、黒字にしたいならスキーム変えないとだめなのよ — Yasuko Ohbaさん (@nay3) 2013年4月25日 でもやっぱり気になっていた
GitHub時代の開発委託とは？ デブサミの資料を公開しました - QA@IT公式ブログ
2013年2月14日と15日の2日間にわたって東京・目黒で開催されたDevelopers Summit 2013（デブサミ2013）の1セッションで、QA@ITの委託開発の話をさせて頂きました。講演40分＋パネルディスカッション40分の構成でした。ご来場くださった皆さま、ありがとうございました。 以下、私の講演パートの資料を公開します。 QA@ITは特殊解か？ パネルセッションの部は、今回お声がけ頂いたデブサミ・コンテンツ委員の和田卓人氏が司会となって、委託側、受託側の双方が登壇してQA@ITの開発の経緯や現状を、SI案件一般との比較で相対的に位置付けるという内容でした。 このパネルセッション中の論点について、1点だけ書いておきます。 資料を見ていただいた方の中には、もしかすると「これは特殊ケースでは？ ふつうの受託ではxxxがyyyなので、こうできないのでは？」とお感じになる方もいるかも
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
TechCrunch
Snapchat has relied on people consuming content on its own app. But now, the social network is allowing websites to embed public content including Lenses, Spotlight videos, Public Stories, and Public Sam Bankman-Fried and other FTX executives spent $8 billion worth of customer funds on real estate, venture capital investments, campaign donations, endorsement deals and even a sports stadium, accord
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
■ - hitode909の日記
音楽とか一緒にやるとアーティストが多数参加みたいになるのにエンジニアが集まると一瞬で人月の神話みたいになるのがむかつく。人月の神話によるとエンジニアを増やせば増やすほどコミュニケーションコストが爆発してゴミの量産が可能になるみたいなことが書いてある。プログラマーはゴミみたいなソフトウェアを作るのが仕事、ゴミを作るだけなら世界にゴミが少ない方がいいからプログラマーいない方がましみたいになってるのがむかつく。エンジニアなめられ過ぎててプログラム書いてるだけでセンス悪いみたいになってて平日に映画見てるだけの文系大学生にも今回の知見を活かして次は頑張れとか言われる。ソフトウェア開発は知的な生産行為だからゴミみたいなものを作るわけにはいかないしゴミが作られる仕組みを作ってはいけない。知性がゴミみたいだったり同僚がごみだったりすることはないと思う。まだまだいいもの作る余地ある。めちゃくちゃいいの作りた
アプリの終わりの始まり
2012年2月27日から3月1日にかけてバルセロナで開催されたMobile World Congress 2012では、特に注目の集まったGoogleやFacebookのキーノート以外にも示唆に富んだ興味深いセッションが多数あった。その中の1つがコンサルティング会社frogのScott Jenson氏によるプレゼンテーションであった。同氏が各地で行っているというプレゼンテーションは“Mobile Apps Must Die”というラディカルなタイトルだが、筆者は大いに共感でき、多大なインスピレーションを受けた。本稿では、同氏の論旨に依拠しつつ、アプリ環境の今後を展望する。 「アプリの海」 現在、AppleのApp Storeでは50万以上、Google Play（旧Android Market）では40万以上のアプリが提供されており、この数は日々増加を続けている。これらに加え、Window
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン
Sharing OptionsShare on Facebook, opens a new window
アジャイル開発の反対はウォーターフォール開発じゃなくて「おまかせ」だと思う - 思っているよりもずっとずっと人生は短い。
メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する（という言い方が悪ければ「最大限許容する」と言い換えてもいい）というものだろう。文書や契約や計画は、あらかじめ（多少はコストをかけて）まとめておけば、それ以降のコミュニケーションは省略できる（ような気になる）、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協
療養費の通知書を作るシステムの仕様がすごい | 水無月ばけらのえび日記
公開: 2011年8月21日15時55分頃 こんなニュースが……「療養費支給額「３兆円」 都広域連合がケタ違いのミス (www.asahi.com)」。 東京都後期高齢者医療広域連合からはおわびの文書が出ていますね。 後期高齢者医療高額療養費支給決定通知書誤記載についてのお詫び (www.tokyo-ikiiki.net)後期高齢者医療高額療養費支給決定通知書の誤記載について (PDF) (www.tokyo-ikiiki.net)本来は「平成23年8月16日」「￥1,351」となるはずのものが、「平成23年80月16日」「￥3,510,000,000,000」となってしまったそうで。 その理由がちょっと驚きです。 同広域連合によると、通知書を作る際、職員がパソコン操作を誤った。支給額欄には１３桁の数字を入れることになっているが、１３５１円を支給する場合も千の位の「１」の前にゼロを９個入力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日の丸家電、打倒アップルの条件 ソフト重視へ転換せよ - 日本経済新聞
特許庁:新システム開発頓挫 東芝子会社と契約打ち切りへ－ 毎日ｊｐ(毎日新聞)
InfoQ: あなたがやっているのはテスティングかチェッキングか？
クライアントの要望にこたえるWebサービス開発 ～「らせん型ワークフロー」のススメ～
