高須 正和： 株式会社スイッチサイエンス Global Business Development/ニコ技深圳コミュニティ発起人 略歴 略歴：コミュニティ運営、事業開発、リサーチャーの3分野で活動している。中国最大のオープンソースアライアンス「開源社」唯一の国際メンバー。『ニコ技深センコミュニティ』『分解のススメ』などの発起人。MakerFaire 深セン(中国)、MakerFaire シンガポールなどの運営に携わる。現在、Maker向けツールの開発/販売をしている株式会社スイッチサイエンスや、深圳市大公坊创客基地iMakerbase,MakerNet深圳等で事業開発を行っている。著書に『プロトタイプシティ』(角川書店)『メイカーズのエコシステム』(インプレスR&D)、訳書に『ハードウェアハッカー』(技術評論社)など medium.com/@tks/takasu-profile-c50fee
マイナンバーカードのメリットのひとつとして総務省が掲げる、コンビニでの各種証明書の取得。しかし今年3月以降、別人の証明書が発行されるトラブルが相次ぎ、サービスが一時停止に追い込まれる事態となってしまいました。何がこのような問題を引き起こしてしまったのでしょうか。今回のメルマガ『週刊 Life is beautiful』ではWindows95を設計した日本人として知られる中島聡さんが、「コンビニ交付システム」の開発運営を典型的なITゼネコンの手に委ねた事が主因と断言。さらに同様の問題を回避するため国が取るべき「ソフトウェア調達法」の具体案を提示しています。 プロフィール：中島聡（なかじま・さとし） ブロガー／起業家／ソフトウェア・エンジニア、工学修士（早稲田大学）／MBA（ワシントン大学）。NTT通信研究所／マイクロソフト日本法人／マイクロソフト本社勤務後、ソフトウェアベンチャーUIEvol
転職・求人情報サイトのtype エンジニアtype スキル なぜソフトウエア後進国の日本で、Rubyは成功したのか？ 生みの親・まつもとゆきひろが語った五つのポイント 2021.09.06 スキル Rubyまつもとゆきひろ 日本発で世界的に使われているソフトウエアは、残念ながらそう多くはない。その数少ない成功例の一つが、プログラミング言語「Ruby」だ。Rubyによって開発された有名Webサービスは、日本だけでなく世界中に数多くある。 では、なぜRubyは成功できて、他の多くの日本のソフトウエアは成功することができなかったのか。2021年9月4日に開催された「type エンジニア転職フェア ONLINE」では、Ruby開発者である、まつもとゆきひろさんに開発の背景や成功の要因を語ってもらった。 まつもとさんの経験に裏打ちされたメッセージは、新たなソフトウエアやサービスをつくろうとするエンジ
まえがき開発中のソフトウェアのライセンスを策定するため、現時点でのベストプラクティスについて探っていたところ、ここ数年の OSS ライセンスの動向が面白かったので復習も兼ねてまとめました。 特に、Umbrel が採用したという PolyForm という新しいライセンス形態が面白かったので、これについて詳しく述べます。 なぜ今ライセンスについてまとめるのか私はソフトウェアやサービスをマネタイズする方法について興味があり、特にビットコインの応用について調べたりしています。 ビットコイン (Lightning Network) を HTTP で利用することで、Web API の課金方法の可能性は大きく広がることは間違いないのですが、これはあくまで単なる支払いの手法であって、広く使われる事を前提としたソフトウェアの開発を支える手法にすることは(それだけでは)難しいという問題があります。 ソフトウェ
鳴り物入りで導入されるもすぐに大規模な不正アクセスが発生、セブンイレブンという企業自体のITリテラシーを疑われる事態にまで発展してしまった、セブンペイ問題。なぜこんなことになってしまったのでしょうか。世界的エンジニアでアメリカ在住の中島聡さんは今回、自身のメルマガ『週刊 Life is beautiful』で、いびつで時代遅れな開発体制を持つ日本ITゼネコンと、そんな組織にセブンイレブンが開発を委託したところに根本の原因があると指摘しています。 ※ 本記事は有料メルマガ『週刊 Life is beautiful』2019年7月16日号の一部抜粋です。ご興味をお持ちの方はぜひこの機会に初月無料のお試し購読をどうぞ。 プロフィール：中島聡（なかじま・さとし） ブロガー／起業家／ソフトウェア・エンジニア、工学修士（早稲田大学）／MBA（ワシントン大学）。NTT通信研究所／マイクロソフト日本法人／
ソフトウェアエンジニアの仕事はいいソフトウェアを書くことなので、別に英語のミスなんか二次的な問題なのだが、Twitterやメーリングリストで、日本人（と思われる）ソフトウェアエンジニアがよくするミスについて、メモしておこうと思う。何かの役に立ったら幸いだ。反響があれば、あとからここに足していくかもしれない。 software/middleware/hardwareは常に単数:softwares/middlewares/hardwaresとはまず言わない。どうしても数えたい時は"a piece/pieces of software"とするのが妥当。 codeも基本的に数えられない:"I wrote codes"とか"I can't deploy codes"とかいう表現を散見するが、これも間違い。ただcodeに関しては、暗号という意味もあり、こちらは数えられます。"Secret codes"
アラン・ケイ Is “Software Engineering” an Oxymoron? By Alan Kay (訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日本語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。) 真のソフトウェア工学はまだ未来のものだ。一年と
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
マイクロソフト、Mac版Microsoft OfficeのソースコードをWindows版のソースコードと一本化実現 20年以上の歴史ではじめて、Microsoft OfficeのWindows版のソースコードとMac版のソースコード、iOS版、Android版のソースコードが一本化されたと、マイクロソフトのプリンシパルソフトウェアエンジニアであるErik Schwiebert氏がツイートで報告しました。 Mac Office 2016 version 16 is now live! For the first time in over 20 years, Office is again built out of one codebase for all platforms (Windows, Mac, iOS, Android)!https://t.co/6gNdKTOEHl — Erik
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
良いテストとはどんなものか，という話をしていて， テストを読めば，そのクラスの使い方や仕様がわかる テストは論文や証明のように上から順番に読めて，上のほうに簡単な一般的な場合，下のほうに難しい，稀に使う場合が書かれている 実装のメソッドと一対一ではなく，ユースケースごとにまとまっている みたいな話をしていた． 機能拡張のさいには，既存のテストを消して，難しい拡張された難しい場合に書き直すのではなくて，既存のシンプルなユースケースも残しつつ，難しい場合を新たに書き足すべき．シンプルな場合を残しておくと，そのクラスを初めて読むときの手助けになる．いきなり難しいケースから始まると，理解が難しくなってしまう．
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
似ているところ どちらも「やっちまったー！」な状態で「前の方が良かったー！」な状態です。 違うところ 同じと解釈する人もいますが、若干ニュアンスが違います。 エンバグは単純に「バグを入れちゃったー！」です。 作っているプログラムや変更しているプログラムにバグを入れちゃったらエンバグです。 解釈にもよりますが、個人的には新規作成中のプログラム（まだ未完成のもの）にバグを入れちゃうのもエンバグであると解釈しています。 ですから、エンバグは後戻りとは限りません。 状況が前に進みつつも、残念な方向に向かうことがあります。 一方のデグレは「前の方が良かったー！」です。 既に出来上がっているプログラムに対する「バグを入れちゃったー！」（エンバグ）もデグレの一種ですが、それ以外にも、以前は有った機能がなくなっちゃったとかの「バグではないけど、やっちまったー！」な状態も含みます。 また、デグレは後戻りです
Dan Bricklin / 青木靖 訳 2016年11月 (TEDxBeaconStreet) Excelのような表計算ソフトを使ったことのある人は、どれくらいいますか？ 大勢ですね。では、フィラデルフィアで小さな印刷業を営んでいた私の父のように、会社の簿記を手計算でやっているという人は？ ずっと少ない。 それは何百年もの間ずっと行われていた方法です。1978年の初めに、私はやがてVisiCalcとなるもののアイデアに取り組み始めました。翌年それは、新製品だったAppleIIパーソナル・コンピューター用に売り出されました。その後の６年の間に大きな変化があったことは、誰もがVisiCalcを知っておりたぶん使ってもいると、ウォールストリート・ジャーナル紙が社説で想定していたことを見ても分かるでしょう。 スティーブ・ジョブズは1990年のインタビューで言っています。「表計算ソフトがPC業界を
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
どう作ればいいか分からないとき，同僚に相談したりするけど，それでもいい方法がなければ，我々のスキルがしょぼすぎて，しょぼすぎるスキルではそういうものしか作れないのだからあきらめて作ろう，ということになる． それはそれでよくて，どんなに実装がしょぼくても，テストは合ってるはずなので，将来的にいい方法が見つかったときに，テストはそのままに実装だけ美しく書き直すことができる． そんな都合よく行くのか，という話だけど，意外とうまくいっていて，ここいけてないなーと思ってたところは半年もすればどう書けばよかったのか分かってきて，初めからそこにあったかのような美しいモデリングができる． 本番環境でプロトタイピングしてるようなものだけど，半年間プロトタイピングを重ねてついにリリースよりは，なんか動くものを今日リリースできるほうがいいし，最初にしょぼいコードを書いているのは，さぼってるわけではなく，技術力が
私はもともと普通のプログラマとしてキャリアをスタートしましたが、2007年くらいから脱プログラマを目指してソフトウェア起業家として経営に軸足を移してきました。 それから8年くらいが経過して思うのは、経営者として大きな成功をおさめる前に、自分のプログラマとしての実力がめきめきとアップしてしまったということです。 8年前の私は、プログラマとしては基礎力はあるものの全般的には未熟であったように思います。コードも荒削りで、とにかくかろうじて動くものを作ることに四苦八苦していました。が、いまはプログラマとしてずっと良い仕事ができています。 この8年間は、自分でコードも書いていたので、経験が増えたことによって、良いコードを書けるようになったという面も多々あるとは思います。しかし、そのあいだ技術書を読むことはすっかりやめてしまい、流行の技術などは完全無視してきました。 経営層の一員として働くので、プロジ
どこがいけてないのか？ クラス名とか、機能名とか、概念とか、名前があると考えやすくなる まだ名前なかったら新たな抽象が見つかるかもしれない どんな経緯でそうなっているのか 最初は抽象を捕らえられていたのが拡張を繰り返すうちに失われたのか、書かれた当初は単純な仕様だったのが膨れ上がったのか、動けば良いという感じで書かれたのか 今の設計のいいところは？ 何か意図や事情があってそうなってるのか、動いてるだけなのか 詳しい人や書いた人に気に入ってるところを聞いても良い みんなどう思ってる？ みんなおかしいと思ってるけど手が出せないのか、これでいいと思ってるのか、など雑談して聞いて回る 最高の状態ならどうなってるべき？ 正しいモデリングや、すごい技術があったら、どうなるか 鋭い分析によって豊かなドメインを得られたり、リコメンドシステムなら脳波を読み取って直接推薦してくれたり、変なドアで世界中好きな場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く