gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー
バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間
QUMAと未踏の話 - 西尾泰和のはてなダイアリー
みなさんもうQUMAの動画はみましたか？日本のベンチャーが開発し、英語のプレスリリースがないにもかかわらずすぐにThe Washington Postなどで取り上げられたあのQUMAですけど。 QUMAの衝撃が世界各地に広がっていくのが観察できて面白いからTwitterでQUMAを検索して眺めていたんですけども、そしたらこんな発言を見つけました： QUMAは、元々ハッカーズカフェで知り合った西尾さんから紹介された人が企画してたので、ハッカーズカフェ発祥と言ってもいいと思うの。 http://twitter.com/#!/doodoo_jap/status/94392093094576128 これ本当です。モノが出来るまでには当事者しか知らない長い歴史があるもので、その事実ひとつひとつを大切にしたいと思います。 http://twitter.com/#!/3DGAN/status/94416
もっとよいGitチートシート - 西尾泰和のはてなダイアリー
世の中にGitのチートシートはいくつかあるけど「Gitを知らない人に渡して最初に読んでもらうのに適したもの」が見つからない。チートシートじゃなくてチュートリアルと呼ぶべきかもしれないけど、とにかく印刷してA4で1枚になるくらいの資料が必要だ。Gitに触れた技術者が軒並み同じ落とし穴でコケるのは正しい状態ではない。「Gitには、indexっていう『コミットする前にワークツリーで行った変更のうちのどの部分をコミットするか整理するための場所』があるんだよ」とか「git revertはsvn revertと違っていきなりリポジトリに変更を加えるから気をつけて」とか最初に言ってもらえればもっとスムーズに進めたはずだ。 というわけでどういうチートシートが必要かに関して考えてみる。 登場人物 http://www.ndpsoftware.com/git-cheatsheet.html このチートシートが
焼畑農業をやめるために---新卒準備カレンダー 2011春 - 西尾泰和のはてなダイアリー
by Lior Shapira under CC BY-NC-ND 2.0 このエントリーは新卒準備カレンダー 2011春という、みんなで仕事に関して自分が考えることなどをエントリーに書いていく企画で書かれたものです。 渋川さんの話を聞く会のつもりが、なぜかいつの間にか名前入りで「新卒準備カレンダー 2011春 : ATND」を作られていたので、空気を読まずに農業の話をします！！ お前だれよ？ 西尾泰和と申します。サイボウズっていうグループウェアの会社のサイボウズラボっていう研究部門子会社で、まあ研究とかをしています。一番最近のアウトプットはこのブログの右サイドバーに出ている「 Amazon.co.jp： WEB+DB PRESS Vol.60」で「言語設計の基礎知識」という特集を書いたことかな。そうそう、3年くらい英語版のプロフィールページしか更新していなかったら3年前の日本語版を最新版
新卒準備カレンダー 2011春について - 西尾泰和のはてなダイアリー
新卒準備カレンダー 2011春 : ATNDという面白げな企画があって、僕も参加しているのですけど、原稿を書いたり、他の人の原稿に対する反応を見たりして思ったことをTweetしたので、流れ去らないように転載しておく。 発信者が良かれと思って書いていることでも、それが受け手にとってもよいものである保証はない。極端な例としては発信者が宗教にハマっている時とかね。だから発信者は「よい生き方」を発信できているなんて思い込んではいけない。「よい生き方だと自分が信じている方法」と「その結果」しか語れない。 人生にはよい時も悪い時もある。世の中には人生を楽観している人も悲観している人もいる。ネガティブな感情になったときに、ネガティブな文章を書いて周りの人の感情をネガティブにする人もいるし、ネガティブな時には黙り、ポジティブな時に語りかけて周りの人の感情をポジティブにする人もいる。多様 読者のことを考えて
「言語設計の基礎知識」本日発売！ - 西尾泰和のはてなダイアリー
僕が書いた特集記事「言語設計の基礎知識」が載っているWEB+DB PRESS Vol.60が本日発売になりました。 書店店頭でどっさり平積みになってました！ どんな特集？ 第1章がまつもとさんに書いていただいた導入で、残りの2〜6章を僕が書きました。ざっくりとキーワードを挙げると: 第1章 言語設計者の視点から見える新しい世界(まつもとさん) 第2章 プログラミングの歴史 プログラミング言語は何のため？ プログラミング言語は人間が作った 第3章 文法の発展 文法はなんのため？ FORTH Lisp 構造化プログラミング 関数 第4章 変数とスコープの歴史 変数はなんのため？ 名前の衝突 有効範囲をわけよう 動的スコープ 静的スコープ ネストした関数 単一代入 クロージャ 第5章 オブジェクト指向の歴史 オブジェクトはなんのため？ ALGOL モジュール PerlのOOP ハッシュ Java
執筆しました: 言語設計の基礎知識 - 西尾泰和のはてなダイアリー
WEB+DB PRESS Vol.60 最近「原稿が原稿がヒー」と言っていたのはこれを書いていたからです。昨日無事入稿できました。ホッと一安心。 第1章がまつもとさんに書いていただいた導入で、残りの2〜6章を僕が書きました。ざっくりとキーワードを挙げると: 第1章 (まつもとさん) 第2章 プログラミングの歴史 プログラミング言語は何のため？ プログラミング言語は人間が作った 第3章 文法の発展 文法はなんのため？ FORTH Lisp 構造化プログラミング 第4章 変数とスコープの歴史 変数はなんのため？ 動的スコープ 静的スコープ ネスト 単一代入 クロージャ 第5章 オブジェクト指向の歴史 オブジェクトはなんのため？ ALGOL モジュール PerlのOOP ハッシュ JavaScriptのOOP クラス C++のOOP SmalltalkのOOP クラスが持つ3つの役割 第6章 継
C++の設計と進化(D&E) レバレッジメモ 1 - 西尾泰和のはてなダイアリー
どこにどの話題が書かれていたかすぐに探せるようにレバレッジメモを作ろうとしたがさすがに一気に作るのは無理だった…C++の話になる前に力尽きた。ふー、これでやっと1/4くらいかー。次回はC++の章からやる。 ~第0章 ある人はD&Eを単なる歴史書と呼んだが…C++がなぜこのようにあるのかを理解することはプログラマがそれを使いこなすことを助ける。道具に対する深い理解は専門的な熟練工にはべからざるものである。 Simulaの最も初期の段階からコンテナは押し付けがましかった。Objectのようなクラスから派生していないと格納できなかった。intなどの基本型は入れられなかった。取り出すときにはObject型になってしまいキャストが必要だった。配列はユーザ定義型を格納できず、参照のみを格納できる。Smalltalk, Java, C#も同様の問題を抱えている。 STLのコンテナはとても不恰好に見えたが
クラスが持つ3つの役割 - 西尾泰和のはてなダイアリー
某所のチャットで話題になって、流れ去りそうだったのでもったいないから転載しておいた。事後承諾で。 MIYAMOTO Daisuke: 型の継承と実装の継承を区別する方法がないんだよな。 西尾泰和(nishio.hirokazu): 型を継承させずに実装を継承させたい→それ移譲で ってことかな？ MIYAMOTO Daisuke: そそ。そもそも、クラスに「型としての役割」と「実装としての役割」という複数の責務があることに、俺は長い間気づかなかった。これに気づかないと、型継承と実装継承が頭の中で整理できない。 西尾泰和(nishio.hirokazu): 僕が最近気づいたことも加えると、クラスには「ユーザ定義型」「インスタンスを作成する道具」「実装の再利用の単位」という3つの役割がある。 MIYAMOTO Daisuke: あぁ、インスタンスの生成器ね。 西尾泰和(nishio.hiroka
多重継承まとめ - 西尾泰和のはてなダイアリー
JavaはInterfaceという特殊な実装を持たないものだけ多重継承できる。実装を多重継承する仕組みはない。同じシグネチャのメソッドを持っている2つのInterfaceを継承した際にエラーにならないので衝突に気付けない。 Pythonはクラスを多重継承できる。同じ名前のメソッドを持っている2つのクラスを継承した際にどのメソッドが呼ばれるかはC3線形化を使って決定される。see: A Monotonic Superclass Linearization for Dylan RubyはModuleという「なにかを継承することはできなくてインスタンス化もできないもの」だけは多重継承できる。Moduleが別のものを継承できないためメソッドの解決は素朴な探索でOK(include A include BしたらBでの実装が優先) SmalltalkにはTraitという実装の多重継承ができるしくみがあ
SPYSEEの会社に遊びに行ってきました - 西尾泰和のはてなダイアリー
先週の金曜日、id:amachangの新しい会社(オーマ株式会社)に遊びに行ってきました。 正直なところ、最初に話を聞いたときには誰か悪い人に騙されてるんじゃないかとか思ったけども、中を見てみたらアットホームな雰囲気のベンチャー企業でした。目標が熱い！世界を変えるSPYSEEへ！ 受託抜きできちんと黒字化してるところや、良好な産学連携関係を構築しているところも考えると、世の中のベンチャー企業の中ではかくだんに「いい会社」の部類に入ると思いました。amachangが入ることでどんな化け方をするのか、今後が楽しみです。 ちなみにamachangが弊社を退社した日の僕のエントリー「SPYSEEのトップに美人画像が出るようになっている！」は伏線だったのですが、転職先予想トトカルチョ #amatoto には影響を与えなかったようでした(苦笑) id:yukobaの「@yukoba なるほど！もっと燃
HTMLで雑誌の原稿を書くためのツール - 西尾泰和のはてなダイアリー
こんなの作った モチベーション テキスト形式での納品を求められるけども、もうちょっとメタデータの乗せやすいフォーマットで書きたいなぁ、ついでに言えば自分が今どれくらい書けているかのイメージを掴む上でも、人に渡してレビューしてもらうにしても、編集しているものが手軽に見やすい形にできるといいなぁ。プログラムで扱うのが楽なフォーマットがいいなぁ。ってそれHTMLでいいんじゃない？ 過去の実装 Jython本を執筆するときは「求められているテキストフォーマットに最低限のメタデータを載せられるようにした独自フォーマット」からHTMLと納品用テキストに変換していたが、メタデータの載せにくさと自分の書いている原稿のプレビューのたびに変換スクリプトを走らせるののめんどくさにこのアプローチはダメだと思った。 現在の仕様 1行23文字、1ページ42行、1ページ2カラム構成の紙面を想定。 JSとCSSで真面目に
リストの比較 - 西尾泰和のはてなダイアリー
id:Yoshiori said Python って list の中身が同じかどうか調べるのって何かやり方ある？？ >>> a = [1, 2] >>> b = [2, 1] >>> a == b False これで True が返る方法 で、僕の返答: >>> set([1, 2]) == set([2, 1]) True 同じものが複数個あってその個数で区別をしたい場合、つまり [1, 2]と[1, 2, 2]は別物とみなしたいって場合はsortedでできる >>> set([1, 2, 1]) == set([2, 1, 2]) True >>> sorted([1, 2, 1]) == sorted([2, 1, 2]) False まあ、でもそういう比較が頻繁に行われるんだとすると、リストってデータ構造で持っているのが合理的じゃない可能性も考えられるね。特にリストがでかい時には毎
初iPhoneアプリがリジェクトされた - 西尾泰和のはてなダイアリー
10月14日にSubmitして10月29日に返事が来ていた。以下翻訳。こんな丁寧な解説がくるのか〜。そりゃ多少時間がかかっても仕方がないなぁ。「iPhone Application Programming Guideを読め」的な1行コメントがくるのかと思っていたので逆に驚いた。こんなに丁寧に教えてもらえるんだったらリジェクトされても逆に勉強になるな。 - にしおさん、 ConicFilmのAppStoreへの投稿ありがとうございます。 我々はConicFilmをレビューし、このバージョンのあなたのiPhoneアプリをAppStoreで公開することはできないと判断しました。理由は、このアプリが iPhone Developer Program License Agreement の 3.3.5章「アプリはHuman Interface Guidlinesおよびその他のAppleが提供するドキ
TAGBOAT SUMMER AWARD 2009で入選しました！ - 西尾泰和のはてなダイアリー
追記：なんと審査員特別賞を頂きました！最終審査結果とインタビューの結果：アーティストの声 Make: Tokyo Meeting 03で下書きを展示していたVirtual Starが、@GALLERY TAGBOATで開催されていたTAGBOAT SUMMER AWARD 2009（TAGBOAT サマー・アワード2009）で入選しました！ Make: Tokyo Meeting 03で「コンビニプリントでA3に印刷してみたもの」を展示した反応を見ていて「やはりこれはやらねば！」と思い急遽アワード応募用のバージョンを作り始めて締め切り2日前になんとか完成させて応募しました。写真がうまく撮れなくて暗い印象になってしまい、さらに前回が応募総数280作品で第一次通過61作品の4倍強の競争率だっだということを知って自信をなくしつつあったのですが…ふたを開けてみると無事入選でとってもうれしいです。
レバレッジメモ「現代アートビジネス」 - 西尾泰和のはてなダイアリー
現代アートビジネスを読んだのでレバレッジメモ 本来アートは自由 同時代に生きる誰もが共有できる財産 日本のアート業界は閉鎖的 誰も見たことのないものに価値を見いだすギャラリストの仕事 従来のXの枠組みを超えて新しい価値観を定義 作品の背後には必ず生身の人間がいる アーティストを育てる売り方 駿馬と伯楽 ギャラリストとは: 広い意味では画商に含まれるが展示空間(ギャラリー)を持ち、みずから企画展示をする 現代アートの展覧会で作品が売れた場合、代金の半分がギャラリーの売り上げ アメリカのギャラリーの多さと多様さに驚いた 帆船の絵だけを扱うギャラリーなど 「こんなものが売れるのか」と思うような作品が目の前で売れていく アート以外の分野でも安いものや粗悪品だって買う人はいる。どんな作品でも交換が成り立てばマーケットができ、お金の流れが生まれる。 グラマシー=アートフェア ホテルの一室をギャラリーに
Make: Tokyo Meeting 03で展示した日記 - 西尾泰和のはてなダイアリー
観客として参加するつもりだったのだけども、結構な人数に「何も出展してないの？」って聞かれたのと、やっぱり何か出展する方が楽しそうだなぁ、ってので土曜日に帰ってきてから日曜までに作れそうなものを頭をひねって頑張ってみた。 とは言っても家にプリンタすらないハードウェア弱者が夜中にできることにはとても限りがあって、コンビニプリントのA3印刷を使うのと過去に作ったものを引っ張りだしてくるのとくらいしかできなかったんだけど。過去のを引っ張りだすにしてもレゴブロック製二進カウンタは解体してしまったし、磁石の立体もばらしてしまったし、であんまり残ってないんだよな。形のあるものって保管コストが高いから。 上は、とりあえずURLとメールアドレスと名前と、空いた隙間に謎掛けを一つ入れた名刺。意外と評判が良かったので前々から作らなきゃって言いつつ作っていない個人用名刺はこれでいいかな。でも顔も入れるべきなんだよ
Make: Tokyo Meeting 03 - 西尾泰和のはてなダイアリー
参加中 OuchさんがTheo Jansen機構のペーパークラフトを作れるワークショップをされていたのでさっそく参加した。Theo JansenはGAを使ってあの寸法を作り出したらしい。なるほどなー。生命を模倣しようとする試みは何百年も前から繰り返されてきたわけだが、現代に生きる我々にはコンピューターという強い味方がいるわけだ。 バクテリアを使ったバイオメディアアート 岩崎秀雄 研究室 早稲田大学理工学部 がすごかった。残念ながら動画は公開されていないようだけど。 あと光ファイバーを回転させることで不思議な物体を作り出している展示が面白かった。 エントリーを書くよりもなんか作らなきゃという衝動の方が強いが何を作ろうかなー。
プログラミングの古典コピペ - 西尾泰和のはてなダイアリー
プログラミング格言集 via @voluntas Classic Programming Quotes | Storm Consultancy Blog 面白い。僕もオリジナルの方を読んで面白いと思ったものを翻訳することにしよう。 premature optimization is the root of all evil 早すぎる最適化は諸悪の根源 --- アントニー・ホーア Walking on water and developing software from a specification are easy if both are frozen. 水の上を歩くのも、仕様に基づいてソフトウェア開発するのも、どちらも簡単だ。それが凍結しているのなら。--- Edward V Berard(Essays on Object-Oriented Software Engineeringの著
男の子牧場の問題点 - 西尾泰和のはてなダイアリー
http://company.nikkei.co.jp/compinfo/compinfo_detail.aspx?CONT_ID=00020821 http://otoboku.jp/ 多く語るまでもない。2点だけ指摘しよう。 「友達承認された会員同士、登録された男性データを閲覧することが可能です。」と書いてあるので「友達同士でしか閲覧できない」と誤解しやすいが、アカウントを作ってログインするだけで、知らない女性が登録した知らない男性の顔画像や女性の書き込んだ情報を見ることができる。 「男性プロフィールの登録は、男性本人の同意が必要となります」と書いてあるが、すでにウサギやぬいぐるみが登録されていることからもわかるように「男性本人の同意があったかどうか」を確認する仕組みは一切存在しない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
