エスカレーターはどう見ても階段なのに止まってなければならないなんてアフォーダンスに反するよなあ 2013-10-23-3 [Design] エスカレーターで歩いて(走って)追い越す人のために片側をあけておく習慣について。 「エスカレーターでは片側を開けず、並んで立つ」を少しずつ浸透させたい (頭ん中) http://www.msng.info/archives/2013/10/escalator.php 非常によく分かります。危ないですよね。啓蒙していきたいところです。とはいえ、苦難の道。 特に駅のエスカレーターは啓蒙では無理かと。あれだけアナウンスしても駆け込み乗車減らないし。 なので、デザインで解決ですね。やはり、一人幅のエスカレーターを増やしていくしかないかと。子供と並ぶ場面も考えて1.5人幅くらいがいいかな。さすがに追い越しできないだろうし。 まあ、そもそも階段なのに止まってなけれ
Ginza.rb.第8回を開催しました。今回は参加者の方に事前にGemfileをアップして頂き、使用しているgemについて説明をして頂く形式で実施。 Gemfileの置き場は[こちら](https://github.com/ginzarb/meetups/issues/6)。 話に上がったgemについて以下にずらずらと。 ### [gon](https://github.com/gazay/gon) Rails側の変数をJavaScriptに渡す事が出来るgem。 controllerから大量のデータをJavaScriptに渡す必要がある場合に便利。 詳細は[RailsCast](http://railscasts.com/episodes/324-passing-data-to-javascript?language=ja&view=asciicast)参照。 ### [Better E
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
The bond between HTML5 and Native has arrived. AngularGap is a beautiful front-end framework for developing hybrid mobile apps in HTML5. Download (alpha preview) MIT Licensed - v0.9.0 Alpha Learn more Create hybrid mobile apps with the web technologies you love. Free and open source, AngularGap offers a library of mobile-optimized HTML, CSS for building highly interactive apps. Built with Sass. F
先日「どうしたらそんなに新しい物事を吸収できるんですか?」ときかれたので、思うところを少し書いておこう。 そもそも物事を習得するスピードは、雑にいえば以下の組み合わせによって決定する。 スペック的な意味での頭のよさ 習得にかける時間 どんなことでもすぐに習得できるほど頭のよい人ならともかくとして、たいていのひとはそうでもないのだから、時間をかけるしかない。つまり、たいていのひとは(1)についてはほとんど変わらないので、あとはどんだけ時間をかけるかという話になる。 そうなると、冒頭の問いに対する答えは「暇だからっすね〜」というものになって、それはそれで真実なのでしかたがない。実際、私は仕事をする以外には特にやるべきこともないので、たいていは酒を飲むか、なんかしらの学習をするかしている(もちろん、酒を飲んで学習を放棄している時間のほうが圧倒的に長い)。 じゃあ、たとえば家庭があるとかでどうにも
By Aidan オンライン写真編集サービスの「Picnik」とウィジェットエンジンの「Phatbits」はGoogleによって買収されたスタートアップ企業です。2つの会社を設立した元CEOのジョナサン・スポサト氏がGoogleへ事業を売却した経緯から、「Googleに事業を買収される前に知っておきたかったこと」をブログで公開しています。 What I Wish I Had Known Before Selling to Google | Inc.com http://www.inc.com/magazine/201402/jonathan-sposato/lessons-from-selling-to-google.html 2004年にウィジェットエンジンの「Phatbits」を設立したジョナサン・スポサト氏は、わずか1年後にGoogleから事業買収の打診を受けました。交渉はスピーディ
片手だけでピッと閉められるマグネットファスナーが革命的に便利そう2013.10.19 17:009,115 mayumine これは革命的…! Under Armorが開発した「Magzip」は世界の全てを変えることは出来ないかもしれないけれど、このテクノロジーを一目見て、衣服の歴史の中でも類をみないほどの進化をもたらすと思いました。 大げさだって? だってほぼ魔法みたいなんですもの。 ファスナーの先の部分、スライダーでうまく嵌められずにイライラしたことがある人は星の数ほどいるでしょう。 このUnder Armorが開発したファスナーの新しいアプローチ。強力なマグネットを利用することで、ファスナーの先の留め具が自動的にピッと磁力でくっついて、簡単に片手で服が着れるようになりました。 これは便利だ…。 このMagzipは、スコット・ピーターという1人のエンジニアのアイデアから生まれました。マ
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
photo credit: miguelavg via photopin cc 技術的負債は少しずつ蓄積されていきます。 技術的負債が何を指すのか、相手によって一部しか理解されないことがあるので、まとめてみました。 基本的にシステムの「品質」を構成する要素を逆に捉えただけなので、ここでは品質の構成要素をまとめます。 参考:アプリケーション アーキテクチャ ガイド - 品質特性の章 by Microsoft 設計 システム構造 全体が一貫性のある構造になっているか。 たとえばUIにビジネスロジックが入り込んでいないか。 保守のしやすさ 機能拡張しやすい構造か。 また、バグを修正しやすい構造か。 たとえば必要に応じて必要なモジュールのみを修正すれば対応できるようになっているか。 流用しやすさ 他のシステムにも流用しやすい構造か。 たとえばそのシステム以外にも同じUIコンポーネントをそのまま流用
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 開発はみんなでやると楽しいですよね! チャットワークなど企業向けにオンラインでコミュニケーションを促進しようとするサービスが多数あります。個人向けであればLINEやTwitter、Skypeもその一つといえるでしょう。しかし開発者にとってはどうも手に馴染まないものが多いです。 プログラマ、デザイナにとって必要な機能に特化させられれば、より開発がスムーズになるかも知れません。その一つになるかも知れないのがDevHubです。 DevHubの使い方 外部サービスから通知を受け取れるようになっており、JenkinsやSubversionからコミット時などに通知を受け取るための設定が書かれています。もちろん他のシステムからもWeb APIを叩けば通知が使えます。 # Subversionの例
ポール・グレアム「クリエイターのスケジュールと経営者のスケジュール」を翻訳しました。 原題はMaker's Schedule, Manager's Scheduleで、原文は http://www.paulgraham.com/makersschedule.htmlです。 翻訳にあたり、TeX様、h小林様のアドバイスをいただいています。ありがとうございます。 英語に強い皆様、人力検索やコメント欄でのアドバイスをよろしくお願い致します。 クリエイターのスケジュールと経営者のスケジュール Maker's Schedule, Manager's Schedule 2009年7月 July 2009 プログラマが大の会議嫌いである理由の1つは、プログラマのスケジュールは他の人とは異なるからだ。会議はことにプログラマにとって負担となる。 One reason programmers dislike
Live Nation says its Ticketmaster subsidiary was hacked. A hacker claims to be selling 560 million customer records. An autonomous pod. A solid-state battery-powered sports car. An electric pickup truck. A convertible grand tourer EV with up to 600 miles of range. A “fully connected mobility device” for young urban innovators to be built by Foxconn and priced under $30,000. The next Popemobile. Ov
米フェイスブックが190億ドル(約1兆9千億円)を投じ、スマートフォン(スマホ)向けの無料対話アプリ(応用ソフト)最大手ワッツアップを買収する。利用者が4億5千万人超とはいえ、従業員は約50人。小さなベンチャー企業に2兆円近い値段がついたことは市場関係者を驚かせた。株式上場が噂されるLINEの"株価"にも影響する可能性がある。わずか11日間で1.9兆円買収まとめる「話を持ちかけたのは11日前
2013年12月末をもって、はてなを卒業しました。また、合わせて結婚生活からも卒業しました。 金曜日は、はてなの人たち有志が慰労会を開いてくれました。 はてなではいつもホストの役目で誰かを見送る立場だったので、自分がパーティの主賓なのが不思議な感じでした。四条御幸町のカフェは貸し切りで、ドアをあけると懐かしい顔が迎えてくれました。 幹事の労をひきうけてくれたid:chira_rhythm55の司会でパーティは始まり、id:jkondoが乾杯の挨拶と音頭をとって、id:nmyが作った342枚の写真からなる思い出のスライドショーを眺めながら、皆で呑みました。京都リサーチパークの4平米のブースで始めた2001年の創業期、東京へ移動しメンバーが増えた2004年、アメリカへ渡った2006年、京都に戻った2008年。大画面には懐かしいメンバーの姿やしなもんが映し出され、ネット上でユーザーさんを巻き込ん
ぼちぼち更新を再開していきます。今年に入ってから、主に寄稿や書籍執筆で経営者への取材が増えました。毎日のようにスタートアップの経営者に取材するわけですが、取材対象企業のビジネスモデルが上手くいく確信を持って取材しているわけではありません。 懐疑的なモデルもあるのですが、スタートアップ経営者に取材しているとその世界が本当に実現しそうな気がしてきて「自分の考えの方が間違っているのかもしれない…」と思わせられることが少なくない。 そんな話をUmeki Salonに投げてみると、コミュニティファクトリーの松本お姉様が「現実歪曲空間」の話ですねとコメント下さり、なるほどなと。リンク先のwikipediaから重要な点を抜粋。 実現困難性についての規模感や距離感を歪ませ、今手元にある作業が容易に実行可能な気になると言われている。RDFは非現実的と非難されてきたが、 ジョブズに近い人々によると、不可能と見
Update: WhatsApp experienced an outage for around 210 minutes today from 11am to 2:30 pm PST. Users around the world reported that they were unable to send messages, and WhatsApp confirmed these problems at 12:16pm PST with a tweet stating “sorry we currently experiencing server issues. we hope to be back up and recovered shortly.” https://twitter.com/wa_status/status/437319926605680640 WhatsApp s
ネット上の広告として最近目につく「マウスオーバー(マウスオン)広告」。クリックしなくてもカーソルが触れただけでブラウザいっぱいに広告が表示されたり勝手に動画が再生されたりして、正直ウザい。そう思っているのは記者だけでなく、ツイッターでちょっと検索しただけでも「マウスオーバー広告ウザすぎ」「死ね」「滅びろ」と怨嗟の声が渦巻いている。その広告を出している企業を名指しで批判するツイートも多々あり、広告としてむしろ逆効果なんじゃないかと心配になるほどだ。 実際、今回の記事のために意見を募集したところ、「広告自体を否定はできないけど、アレは好感度アップにはつながらない。強引すぎる」「今現在見てる記事を邪魔するように出てくるマウスオン広告に嫌気がさして広告ブロックを導入しました。今までバナータイプの広告なら気になる広告はクリックしたりしてましたが、マウスオンは不快感でしかなく何の広告だったかも覚えてま
書き出してみてふりかえったけど、たいがい重箱系だったのでQiitaの人しか興味はないかも。 (UX)「送信」ボタンを押すまで著者へ補足コメントできるかどうかわからない 他人の書いた文章を手直しするわけだからそれなりの理由を相手に伝えることは当然で、もちろんその情報の入力フロー自体はあるんだけど、それが「送信」ボタンを押すまでわからない。 「送信」を押したらそのまま相手にぶしつけに書き換えた内容が送られてしまうのかと不安だった。 もちろん1回体験すれば次からはとくに気にならない。 また通常のQiitaのウェブインタフェイスの記事の更新操作に慣れている人は、submit後に更新の要点(コミットメッセージ相当)の入力が則されるので違和感はないのかもしれない。 (Design) その変更が妥当かどうか正解がないケースで編集リクエストは活用できない 正解があるというのは内容が事実と異っていることが明
久しぶりに技術カンファレンスに足を運んだ。仕事が今日ばかりはどうしても忙しかったので、後半戦からの参加だったけど。 技術カンファレンスに行くと、技術力の高いエンジニアの発表にいつも圧倒されて、「もっと技術的な高みを目指してかないと、将来絶対にいつか食えなくなるなぁ」と本当に危機感を抱く。今日一番印象に残った発表では、「自分が技術的に成長できてるかをいつも問うことが重要。高い技術レベルを持ってないと、組織の下駄を脱いだときに何もできない(俺意訳)」という発表だった。全くもって真っ当な正論だと思う。何も間違ったこと言ってないと思う。 一方で同時に、それとはまったく反対のことも思う。 今、エンジニアリソースやエンジニアのスキル不足が直接の原因で、業績が伸び悩んでる会社ってどのくらいあるんだろう? 大概の会社って、技術的リソースよりもアイデアのほうが枯渇したがゆえに業績が伸び悩むんじゃないかなぁ。
今更ながら Podcast にはまってしまった Podcast を先月から今月にかけて聴き漁っていた。 芸能人の Podcast なんてものには興味ないので、 聴くのはもっぱら、Tech Podcast。 ただ、iTunes Store で探したけど、日本のエンジニアがやってる Podcast ってあまり無かった。 iTunes Store だけ、っていう探し方が悪いのかもしれないけど。 自分が購読している Podcast を紹介してみる。 英語力が残念なため、日本語ばかりなのはご愛嬌。 Rebuild Rebuild - Podcast by Tatsuhiko Miyagawa Perl の神こと miyagawa 氏の Podcast。 そのときホットなニュースやテクノロジーが話題の中心。 印象に残っているのは Infrastructure as Code や Immutable I
昨日の夜買って読み始めたら朝の 10 時に読み終わった。いろんな人がいろいろ感想書いてるからごちゃごちゃ書くことはしない。 「利口な UI」というコラムが序盤にあった。これは「バカにプログラミングさせるとビューにロジックが集中する」「かといってバカにはモデル駆動開発は無理」という話です。極めて説得力を感じるのですが、この問題に関して最後まで読んでも特に解決策は載ってませんでした。 優秀なエンジニアがその辺にいくらでも生えてるということは稀なので、教育とかいう難しいやつをやる必要がある(難しい) — トデス子 (@todesking) February 22, 2014 というようなのが現実だと思います。ここから得られる課題は、「利口な UI」しか書けない人をどのようにモデル駆動開発に耐えられる専門家に教育するかという点です。 ある程度の人間が「ビジネスサイドの人間と会話する共通の言語を基に
AppBank NetworkのローカルCocoaPod化が完了した!投稿者: Naoki 投稿日: 2014-01-27 AppBankNetworkのローカルCocoaPod化が完了しました!一応、ログインして申請しないとSDKはもらえないので、CocoaPod本家にはアップしませんが、やり方だけ備忘的に書いておこうと思います。 まず、CocoaPod化前に決めていた前提。 CocoaPod化する際の前提 後でわけがわからなくなるとまずいので、ダウンロードしたSDKのディレクトリ構造は変更しない。 AdMobMediationAdapterは使わない。 ローカルのgitで管理する。 /NendSDK_iOS-2.3.2/の直下にgit initしました。:pathで直接指定しても良かったのですが、他のローカルリポジトリと共通のgit方式にしました。gitだとバージョンの管理が楽なので。
Webサービスにおいて定量的に評価できる数字とユーザー体験はトレードオフであることが多い。たとえば、広告のクリック率を上げようと思えば、広告枠を過剰にチカチカさせたりボタンに隣接させて配置したりすればよい。運営者の小遣いが増える代わりに、ユーザーにとっての心地よさを犠牲にする。 必要なのはバランス感覚だ。価値基準が歪むと"Don't be evil"という言葉も機能しなくなる。 ユーザー体験を犠牲にする黒魔術に一度手を染めると、そのサービスはいつしかスパムと区別がつかなくなる、と僕は思う。 “月間34億PV、新規会員登録1日1万人! pixiv片桐代表が明かす、驚異のグロースハック術 | ログミー[o_O]” http://t.co/q36cwDbmeq— ウイウ (@uiureo) 2014, 2月 17 会員登録しないと著しく不便なようにして無理やりユーザーに登録させるのをグロースハッ
いわゆるパクリサービスって、なかなかうまくいかないことが多いと思います。 もちろん全てが失敗するとは限りませんが、模倣してもうまくいかなかったものに目を向けてみると、その失敗理由にはいくつかの傾向があるような気がしています。 成功要因を分析し切れていないまず、後追いサービスが先行サービスの成功要因を分析し切れず、自滅するケースが結構あると思います。この点に関しては、僕が昨年最も影響を受けた本「ストーリーとしての競争戦略」の中でも深く考察されています。(以下、同書から抜粋) 競合他社はオリジナルのストーリーが内包していた交互効果の妙については十分に理解していません。場当たり的に戦略を模倣しても、オリジナルの戦略の競争優位の本質であった交互効果は発揮できません。戦略が不全をきたし、かえってちぐはぐなことになります。 このような自滅の論理は、競争優位にある企業のオリジナルな戦略ストーリーに一見し
Qiitaとブログの違いがわからないと思ってたがだいぶ違うってことがわかった ブログでは記事に間違いがあった時にコメントで指摘して著者が修正するしかないが、Qiitaではプルリクエストを投げられる(投げてくれるかどうかわからないけど) 間違いがあって修正した時に、その記事を「ストック」している人に変更通知を飛ばすことができる Kobitoってアプリがあってローカルでリアルタイムmarkdownプレビュー Kobitoなら画像のアップロードもドラッグドロップでよい、Gistでは面倒 Emacsで編集してKobitoでリアルタイムプレビューも可 投稿データをJSONでダウンロードできる、他人のも テンプレートを作れるので社内Wiki的に同じフォーマットで複数の人が書く場合に揃えるのが楽 コメントを書いたりするのにgithubやQiitaのアカウントが必要なので非エンジニア避けになる 外に見えて
WhatsAppはなぜ欧米で成功したのか(なぜ日本では成功していないのか) こちらの記事を読んで、要はSMSが主流だった海外でSMSを置き換えるサービスとしての立場を獲得したことでWhatsappは流行ったという分析がされていて興味を持ったのでもう少しそこの時代背景や他のサービスはどうなのかということを詳しく調べてみました。 Appstore登場(2008年7月)以前: 上記の記事にもある通り、この間はSMSがコミュニケーションの主流でした。しかし2007年にBlackBerryのユーザー同士なら無料でメッセージがやり取り出来るサービスBlackBerry Messangerが登場し、SMSの置き換えをしていきます。 Appstore登場後(2008年7月)以降: 2008年7月にAppstoreが公開されましたが、このすぐ後の時点でもすでにメッセンジャーのアプリは結構ありました。 しかし
Ubuntu desktop moving application menus back into application windows | Ars Technica UbuntuのUnityは、長らくウインドウのメニューをウインドウ自体ではなく、画面上部のバーに表示するUIを採用してきた。これには賛否両論あったが、賛同する者達でさえ、問題点は皆無とは言えない状況であった。 グローバルなバーが表示するのは、現在フォーカスのあたっているウインドウのメニューであるので、ダイアログを開くソフトウェアなどが使いづらい。 Ubuntu 14.04では、どうやらメニューをウインドウごとの表示に戻すようだ。 The world’s fastest VP9 decoder: ffvp9 | Ronald S. Bultje ffmpegによる、最初から自由なVP9デコーダーの実装ffvp9を開発し、Go
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く