もし地球がバスケットボール大だったら? 地図上で太陽との距離を確認できるwebサービス

太陽系の大きさを、身近な地図上で実感するためのサイト Soalar System Maps もし地球がバスケットボールの大きさだったとして、東京日本橋のサイボウズ本社に太陽があったとしたら、 太陽の大きさがこんなで、 バスケットボール大の地球は、国会議事堂あたりを回っているかもしれない、と。 サイトでは、他の惑星を選ぶこともでき、またバスケットボールだけでなく「もしテニスボール大だったら」も選択することができます。 天文学的な距離や大きな量を卑近な例に縮小することで感じる、という教材はよくありますが、自分の家や良く知っている場所を太陽にできることで、さらに理科への興味を持ってもらったりすることもできそうですね。 Angular で書かれたソースコードはこちらで公開されています。 サイトの作者が「この動画からインスピレーションを得ました」と紹介している、もし太陽がサッカーボールだったら各惑星(存在の可能性が言われる第9惑星も)はどこ?

genact – 「プログラマー的な作業をしてる風」に見せるためのツール・ページ

仕事すべき時でも、忙しいフリやコンピューターの処理を待つフリをしよう! 並行して多数の仕事をこなす驚異的なスキルを他人に印象づけよう genact は、プログラマー的な出力を画面に表示するためのツールです。 Rust製のソースはGitHubで公開されています。MaxOS X, Linux, Windows それぞれのバイナリもリリースページに有るので、ダウンロードして走らせるだけでプログラマーな感じのウィンドウが立ち上がります。 ダウンロードが心配であれば、ウェブ版もあります。カフェ等でこれを一個開いて表示しておくと、なんか難しそうなことをしてるように見えるかもしれません。 6つのモードがあり、パラメーターで指定することで切り替えられます。複数のモードを指定すると、適当に切り替えもしてくれるようです。 bootlog cargo cryptomining cc download memdump cryptomining で仮想通過の採掘をしてる風に見せるのなんか、今風でしょうか。 via Hacker

傘を畳むようにコンパクトに畳める自転車/車椅子用タイヤ revolve

ドイツの自動車デザイナー、アンドレア・モセリン氏(Andrea Mocellin)が3年を掛けて開発した新機軸のタイヤ revolve は、26インチのホイールが6分割で折りたたまれると、直径が3分の1にまで縮まるというもの。 [video width=416 height=304 mp4=http://developer.cybozu.co.jp/akky/wp-content/uploads/2018/01/revolve-folding.mp4][/video] モセリン氏は、ニューアトラスの取材に対して、revolve が現在の折り畳み自転車の多くが小径のタイヤを採用せざるを得ないことに対する解決方法であると語っています。 また、畳んだ状態で家の中にあっても美しく見えるのが望ましい、ということで、折りたたんだ状態の revolve はスピーカーやオブジェのようにも見えるデザインとなっています。 タイヤは6つに分かれることから当然エアレスのものになりますが、これの乗り心地はどんなものですかね。 https://vimeo.com/242374901 このプロトタイプ revolve

PlantUMLでAWSサービスを含む図を作る

プレゼンテーション資料をMarkdown形式で書いていて、図を入れたいが図はどうやって用意しようか、となりました。 せっかくテキストエディタでプレゼンを作れるようにしているのに、図を描くのにテキストエディタでなくドローツールを開くのは面倒だな、テキストで図を描ければ、ソースコードとして管理できるから似たような図を量産するのも楽だし、バージョン管理で変更点もわかりやすい。 ということで探したところ、Plantuml が見つかりました。日本語のマニュアルもあるし、評判もいいみたい。 インストールしようとしたところ、図を1,2個作るだけならオンラインでできるようです。試すだけならハードルはとても低い。 マニュアルを参考にして作ったのがこちら @startuml [Github] as github [さくらVPS] as vps [local machine] as localmachine :ユーザー: localmachine :2) Sculpinで変換 :ユーザー: ....>

[可視化] ヨーロッパ各国で「子供の恋人が○○人でも気にしないか?」を訊ねた結果の地図

reddit の地図セクションで bezzelford さんが発表したヴィジュアライゼーション。 この地図は、「あなたの子供が黒人と付き合っていたとして、問題ない(comfortable)と思いますか?」に対する回答で、問題ない人の割合が高いほど緑に、低いほど赤に塗り分けられています。 緑が濃い国ほど、気にしていないということですね(あるいは「気にしてないように振る舞う」可能性もなくはないですが)。同じヨーロッパと言っても、8割は気にしないスウェーデンやイギリスの寛容さと、7割が気にするチェコ・スロバキア・ブルガリア等では大きく違うことが見て取れます。 ヨーロッパで黒人がどう扱われようと、日本人の自分には関係ない? ではこちらはどうでしょう 「あなたの子供がアジア人と付き合っていたとして、問題ない(comfortable)と思いますか?」への回答。 黒人とアジア人の許容度の差は平均で5%ぐらいなので、「子供の交際相手として黒人はだめだがアジア人ならOK」という人の割合は、ヨーロッパ人が20人いる中で1人ぐらいということなんでしょう。人種差別の少ない社会は、日本人にとっても助かる社会と言えるのでは。 reddit のコメント欄では、「国によってその国の言葉で訊ねただろうから、翻訳のニュアンスが違うせいでこんな差がついたのでは?」と言った意見も出ています。「さすがにこんなひどくないだろう」という人もいれば「私も○○人だが、○○人の多くはレイシストだ」みたいな人も。 また、「アジア人(Asian)と言っても国によってさまざまで、たとえばイギリス人ならインドやパキスタン人を最初に思い浮かべるのでは?」とか、「そんなことはない、中国人や日本人をまず思いつく」という議論もありました。 元の投稿では、イスラム教徒、ユダヤ教徒についての地図もあります。 元データについて このデータ、適当なアンケート結果ではなく、EU が実施した「EU における差別 2015年」という大きな調査 [pdf]

Ruby on Rails の PHP 移植プロジェクト

メモ: PHP フレームワークと Ruby on Rails からの影響

PHP 用の Rails クローンや、Rails を移植したと主張しているプロジェクト達

CakePHP
https://trac.cakephp.org/

Biscuit
http://bennolan.com/biscuit/

PHP on Trax (旧名 PHP On Rails)
http://phpontrax.com/

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

ソースコード検索とコピペプログラミング

プログラマー向けにまた新しいサービスが出たようなのでご紹介。

code fetch { は、ソースコードに特化したソースコード検索エンジン。”{” 記号もサイト名の一部のようだ。

関数名などを検索すると、関数名を含むサンプルを、書籍のサンプルコードから抜き出して表示しているようだ。

言語ごとに検索することができる。以下はいくつか試してみた結果。

サイト自身は、紹介した書籍を買ってもらうことでビジネスとするつもりらしい。

ある関数を使うとき、関数の挙動はわかっていても、それを実際にどのように呼び出すのかが、マニュアルからだと簡単に把握できないことがある。

PHP のマニュアル などでは、マニュアルの末尾にユーザのディスカッションをつけて、そこでサンプルコード的なものが流れているが、サンプルから使い方のあたりをつける、という点ではこれも役立つ気がする。

ソースコード検索エンジンとしては、日本にも高林さんの gonzui があるが、同じような技術を基盤に、公開されているサンプルコードと amazon アフィリエイトを組み合わせてビジネス化しよう、という試みと言える。(検索してほしくない本の著者は連絡してくれ、とあるので、このあたりに問題点をはらんでいる可能性はある)

ビジネス的にこれがいけるのか、著者によってはこれを許したくないのでは、という話は別として、こういったソースコード検索によって「他者のソースを見る」という機会は重要なのではないかと僕は思っている。

究極的には、僕らプログラマーが書いているコードのほとんどは、過去にどこかで見た他人のコードを真似て、再構築しているといってもいい。本質を理解せずにコピーした粗悪なコードの氾濫も大きな問題ではあるものの、読むことや真似ることそのものが悪だとは僕には思えない。

ペアプログラミングなども「よいソースを書いている状態を目の前で見る」ことの教育効果が評価されている理由の一つではないだろうか。

検索によって良いお手本が簡単に見つかるようになっていくことは、決して悪いことではないな、と思うがどうだろう。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

日曜は PHP 勉強会

昨日の Java 読書会に続き、日曜は PHP 勉強会に参加してみた。

mixi の PHP コミュニティから発生したらしいこの勉強会、会自体は3回目のようだが、当然これまでは参加していない。何か発表するものを、という話だったので、自分が書いたわけじゃないが CyDE2 の開発環境を持って行き、インストーラとユニットテストをどうやってるかあたりをちょろっと紹介させていただいた。他の発表を聞いてみて比べると、あまり技術的じゃない。宣伝臭いし。

他には、PHP フレームワーク Maple の作者の方が、AOP による DB アクセスの Maple へのウィービングについて実装発表されていて、面白かった。

あとは、PHP に関する洋書のレビュー発表など。アメリカに居たとき本屋でパラパラと見ていた本がいくつか出てきて興味深かった。

全体的に、昨日の Java 読書会が「最近面白い本出てないねぇ」といった感じだったのに比べて、PHP 勉強会のほうが活気があるように見えた。

でも、土曜日にあった Lightweight Language Day and Night (LLDN) に参加されてた方も多く、そちらでは Ruby や Perl のヒトタチが元気だったということで、PHP もがんばらないとね、という雰囲気もあった。

それと、いつも PHP 関連の雑誌記事などでお世話になっている著者のみなさんと直接お会いできたのは非常によかったと思う。来月もあるようなのでぜひまた参加したい。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

土曜日は Java 読書会

Java 読書会 に参加してきた。一冊の本を、毎月一回集まって「読む」というもの。インターネット協会の部会ということになっているが、参加者は興味のある有志の集まりだ。

僕も、転職でアメリカのサイボウズに行く前はよく参加していた。今回はひさしぶりの参加となる。

今回は翻訳者の瀬谷さんにも来ていただき、読んでいて難しい点など直接解説していただくこともあり、非常によかった。

今月分で読了となった、「アジャイルソフトウェア開発の奥義」だが、今回読んだ中で「付録C: 皮肉な運命」が読み物として面白かった。

同じプロジェクトを実施することになった二つの会社の話を、横に二つ並べて小説風に描く、というもので、一つはガチガチのウォーターフォールで大混乱になり、もう一方はアジャイル的な手法でなんとか成功する、というオチ。

悪い方の例では硬直したプロジェクト管理や理不尽な上司の要求、と言ったものが書かれている。思わず「あるある」と言ってしまうところも多い。ちょっとだけ触りを抜粋すると

上司「即刻開始する必要がある。分析にはどれくらいの時間がかかるかね?」
あなた「仕様要求がわからなければ分析にかかる時間を申し上げられません」
上司「仕様要求が出てくるまでには4~5週間かかるだろう。だから、仕様要求が今君達の目の前にあるものと仮定したまえ。君達は分析にどれぐらいの時間が必要なのかね」

さて上記の流れは変だ、とあなたは思うだろうか? あるいは、いったい何がおかしいというのだ、と思うだろうか。

アジャイル開発についての本なので、アジャイル開発に対してちょっと甘いかな、という気もするが、二つを並べて読むことで、果たして自分達の開発プロセスはどうだろうか、という良い自省ができる話かなあ、と思った。

もちろん、本文の方も充実した内容で、XP、デザインパターンについて実例をなぞりながら勉強することができる。いい本だと思った。

Java 読書会 は9月から新しい課題書(まだ決まっていない)で最初からスタートするので、会社の外で業務とは別に勉強してみたい、という方は参加してみてはどうだろうか。

こういった社外の勉強会は、Java 読書会の場合は「Java」というキーワードはあるものの、ウェブサービス系や組み込み系などさまざまな業務をしている人(もちろん仕事は全然 Java じゃないが自分で勉強してる人も)が集うので、見聞を広めるのにも役立つと思っている。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

商用アプリ開発に関する PHP の利点と欠点

現在サイボウズ本社でいちばん使われているコンピュータ言語は、と訊かれれば、それは PHP という言語になるだろう。

PHP はそもそもウェブサイトを作るために開発された、目的のはっきりとした言語で、ウェブアプリケーションの世界では非常にユーザー数の多い言語である。PHP のエンジン部分を開発している Zend 社の調査では、インターネット上のウェブサイトの 20% 超は PHP で書かれているともいう。

また、PHP の言語としての文法は C 言語に似せて作られていて、C 言語風のスクリプト言語といえる。専門学校や大学などの授業で C 言語や C++/Java など C 言語に似た言語が使われることも多いため、比較的とっつきやすいとも言えるだろう。

そういった普及度からすると、PHP を多用することには、プログラマーが足りなくなったときに社外から人材を集めやすい、あるいは協力会社を探しやすい、という利点がある。

2年以上前から準備され、今回発売となったガルーン2 では、この PHP が大きな部分を占めている。それ以前は独自のスクリプト言語(Cybozu Labs 社長でもある畑の名前を冠した、Hata-Script である)を使っていた。これもまぁ、Office6 までのサイボウズ製品を見ていただければわかるように、軽量できびきび動く、いい言語ではあったのだが、やはり PHP のユーザベースの大きさというのは意味がある。

この変更では、内製も含めて様々なオプションが検討されたわけだが、サイボウズ製品の特性や技術者の確保のしやすさ、などいろいろな観点を総合し、PHP が選定された。

ただし、その選定の際には、満場一致ですぐに PHP を使うことに決まったわけでもない。(主に反対していたのは僕だが)

どんな言語も完璧ではありえない。PHP にも危惧されている問題点はあった。言語としての出来、や、インタプリタの安定度、リソースの消費量、処理の速度、利用できるライブラリの量や質、利用や配布に関する制約、などなど、について、問題があるかどうか、あるとしたらどう解決するか、解決法が現実的な対処であるか、といった事柄について多数の討論をおこなった。

そういった技術やライセンスの問題については一つずつ問題点をつぶしてきており、今のところ大きな問題点は残っていないと言ってもよさそうだ。僕自身は早い段階で CyDE2 のプロジェクトから離れており(==米国の子会社に帰った)、実際にそれらの改善を辛抱強くおこなってきたのは本社の開発部の面々である。

それでも残る問題は、一部の硬派プログラマーから、PHP は「初心者向けの言語」と思われていることにある。こればかりは、サイボウズの開発部ががんばるだけで解決する問題ではない。

まぁ、現在主流のバージョン 4、PHP4 では、言語としていいかげんなところや使いづらいところもたくさんあり、技術力のあるプログラマー達の多くが「一番好きな言語」とか「一番使いやすい言語」に選ぶ言語だ、とまでは言えないだろう。

「弘法筆を選ばず」というから、真にできるプログラマーならどんな言語であってもちゃんとした成果を残せるのかもしれない。しかし、実際問題として、そのとっつきやすさ、はじめやすさがかえって災いし、「PHP ができます」という人の中に「PHP *しか*できない人」も多い。

理想としては、どんな言語でもすばやくマスターでき、PHP インタプリタの挙動に疑問点があれば、PHP のソースまで遡って調査することも全然苦にならない、といった人がたくさん来てくれるといいんだろうな。ま、これは主に本社側の話だが。

サイボウズ・ラボでのこれからの開発は、必ずしもサイボウズ本社と同じ言語を使う必要はないため、たとえば PythonRuby のような言語を使ってもよいし、LispJSF/Java でもいい。それは入ってきた人が自分で先導して決めていってしまえばいいのだ。いまのところ、そのへんはまるっきり流動的だ。

むしろ、自分の好きな言語や環境について熱く語れて、まわりを引っ張って巻き込んでいけるような、そんな人であれば面白いし、僕もぜひその人からいろいろ学んでみたいものだ、と思う。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

成功する Web2.0 企業になるための 10 のステップ

成功する Web2.0 企業になるための 10 のステップ より。

  1. 利用者の問題をよく理解したうえで、最小単位から解決せよ
  2. 反応のよい、意見を言ってくれる利用者を獲得せよ
  3. 今すぐ公開せよ。明日公開せよ。毎日公開せよ
  4. データを配布しまくれ
  5. 利用者のデータを囲い込まないこと
  6. おどろくほど単純にせよ
  7. 無料でありつづけよ
  8. マーケティング費用は無駄
  9. 投資しすぎないこと
  10. どのサービスにも見るべき点がある

詳細は元エントリをどうぞ。いくつもの実サービスを例にあげて、成功したネットサービスに共通の要素を解説してくれている。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

akky's work blog