サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
blog.masuidrive.jp
トレタ アドベントカレンダー 2016土曜日担当の増井です。 今日はITとは関係ないDIYの話です。 今の家に引っ越して2年。荷物も増えてきて「服を掛けるところがない・・・」という状態になってきました。 2畳ぐらいのクローゼットはあるのですが、二人暮らしでは全然足りません。このクローゼットの前の部分がデッドスペースになっていうので、ハンガーラックを置こうと思ったのですが、ちょっと狭くて奥には難しそうです。 壁に直接ハンガー掛けをつければ行けそうなのですが、我が家は賃貸なので壁に釘は打てません。 初めは2×4材でフレームを作って・・・とか結構大掛かりなことを考えていたんですが、今は「ディアウォール」っていう便利なものがあるんですね。びっくり。 これを使うと突っ張り棒の要領で家のどこにでも2×4材の柱を設置することができます。 ということで、ディアウォールと2×4材を使って、なるべく手軽に、壁
もうちょっとで新しいMacBook 12″が出ますよね。軽いのにRetinaですごく良さそうなのですが、CPUが非力なのが気になります。 私はサーバサイドの開発がメインで開発環境の構築にはvagrantを使っています。vagrantはメモリもCPUも食うのでMacbookではちょっと厳しそう。特にテストの実行は数十分待たされそうな予感もあり、メインの開発には力不足です。 別にvagrantの実行はローカルホストで行う必要はないので、aws providerを使ってEC2上で動かしてみたりしたのですが、ネットワークやインスタンスコストの問題で常用は躊躇していました。 検索していくと、本家のIssuesでもvagrantをリモート実行する議論が行われていました。そこで紹介されているプラグインを試してましたが用途とは合いませんでしたし、バージョンアップの多いvagrantで使い続けられるか心配で
ここ数年、Javascript界隈でフレームワーク戦争が勃発してきました。クライアント開発の規模も年々大きくなり、jQueryだけでは複雑な画面遷移などを管理しきれなくなってきたのが原因だと思います。 私も昨年までAngularとbackboneを試しましたが、サーバサイドをMVCにしているのに、クライアントでもMVCを作るMVCの2階建ては、やり過ぎなのではないかと思っていました。フレームワークそのもの覚えるまでにも一苦労というのも面倒に感じました。 2014年、海外でブームに火が付いたReact.js そんな中、2014年の後半からFacebook発のReact.jsの採用事例が聞こえてくるようになりました。AirBnBや米Yahoo! Mailなど大手がReact.jsを積極的に採用し出したので気になり、年末年始を使って色々調べてみることにしました。 Rails以来の衝撃 色々試して
うちの掃除は基本的に毎日はないさんがやってくれます。 ルンバは、床に大きなゴミがあったり、コードが這っていると食ってしまうので、事前に部屋をRoomba friendlyにしておく必要があるんだけど、それさえやっておけば、ほとんど掃除機をかける必要がないので凄くラクになります。 とはいえキッチンとかは、徐々にヨゴレが残っていき、雑巾がけをする必要はあります。 めんどいし、腰がやられそうなので、どうしようかなーと思っていたところ、ルンバの会社から雑巾がけのロボットもリリースされてたので買ってみました。「ブラーバ 380t」だから「みやおさん」って呼んでます。 エンジニアとしては、自動化できるところは積極的に自動化して、イテレーションを回すのが大事だと思うし。 ひさびさにガジェットっぽいモノを買った気がするのでunboxingから写真撮ってみました。 サイズはルンバより一回り以上小さくて、重さ
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか？画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
トレタで使っている、チャットで勤怠管理する「みやもとさん」をオープンソースでリリースしました。 https://github.com/masuidrive/miyamoto Slackの#timesheetsという部屋で、「おはようございます」と書き込みと出勤が記録され、「お疲れまでした」と書き込むことで退勤となります。「明日はお休みさせて頂きます」と書き込むと、休暇の届け出になります。 チャットで勤怠管理する最大のメリットは、オフィスに居なくても誰がいつ出勤・退勤したのか全員が分かることにあります。出退勤管理アプリは色々出ていますが、営業で直行直帰する人や、リモートワーカーなどは、帰った時間がリアルタイムでわかりにくいという欠点があります。 「みやもとさん」では、チャットでやりとりする事でみんなの見える形で出退勤が記録され「あ、帰る前にあれも！」など、ありがちなコミュニケーションがスムー
4/1のスクー増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの作り方〜サービスデザイン編に参加頂いた方々ありがとうございましたー。 次回は4/8 21:00〜、もっと技術的な話しをする予定です。こちらも引き続きよろしくお願いします。 wri.peのソースコードを公開したので、先にこちらも見ておいて貰えると、より分かりやすいかも知れません。 人前での講演は多いのですがカメラの前で話した事はほとんどないため、結構緊張しました。後日公開されるビデオは自分では見たくないな・・・w デザインがらみで一つ紹介し忘れたのですが、色を決めるときはCOLOURloversを使っています。 質問をいろいろ頂いたのに授業内で答えられなかったものもあったので、ブログでお答えしたいと思います。 サーバ代 $200/moの内訳 下記に加えて、ドメイン代とSSL代が毎年かかるので、大体毎月$200ぐらいの感じに
昨年末にトレタをリリースして以来、ユーザが順調に伸び、エンジニアが二人ではどうにも困ってきたので、サーバサイドのRails、クライアントのiOSエンジニア、それぞれ1名ずつ一緒に働いてくれる人を探しています。 業務内容としては、トレタの開発、運用全般になります。iOS側はプロダクトオーナーの中村やUXデザイナーと一緒にクライアントアプリの設計・開発、Rails側はサービス全体の設計・開発から運用までを行います。 Railsは私とAutoPagerize作者の沢田がいるので、教えながらもできるのですが、現在iOSエンジニアは社内にはいないので、結構一人でがんばれる人にお願いをしたいです。 いきなり面接！っていうのも堅苦しいので、軽くでも興味のある方は、豚カツか豚しゃぶでも一緒に食べませんか？ 勤務地は目黒で、各種条件や開始時期などは結構柔軟に相談に乗ります。 masuidrive@toret
schooで授業もやるし、まぁ隠しておく意味もないかなーと思ってので、wri.peのソースを公開する事にしました。 https://github.com/masuidrive/open-wripe 全部公開しているので、キーを適切にセットすれば自分で動かす事ができます。 元々、公開するつもりでは無かったので、ソースは読みやすくはなっていません（汗 pull-requestを貰えれば取り込みなども行いますので、興味のある方は直接投げてもらうか、Twitter/Facebookなどで声をかけてください。 4/1からwri.peの作り方を解説する授業を4週間schooで行いますので、興味のある方は聞いて頂けるとうれしいです。 増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの作り方〜サービスデザイン編 増井 雄一郎 先生 – 無料動画学習｜schoo（スクー） Webサービスのつくり方
デブサミ 2014で話した「エンジニアだからできる自由な生き方」の感想を書いてくださっているブログがあったので、まとめてみました。 下記以外でも「あった！」という方はコメントなどで教えて貰えると幸いです。 あと、先日、話忘れた事があって「自由はメンテナンスし続けないとすぐ失ってしまう」っていうのも大事かなと。一発の努力じゃなくて、継続が必要なのがホント難しい所。 2014/02/14 デブサミ2014【14-A-5】エンジニアだからできる自由な生き方 #devsumiA – Togetterまとめ ミイル/トレタ増井雄一郎氏「エンジニアだからできる 自由な生き方」@デブサミ2014 2日目 – tchikuba’s blog Developers Summit 2014の参加記録（後編: 2月14日整形版） : georgenano serious side Developers Summ
昨年の後半から、「エンジニアとしての生き方」のような話をする事があり、ずっと継続して考えてきました。 先日も「一生、エンジニアであり続けるために必要なこと(レポート)」という講演をしたのですが、実はその時点でもまだ自分で分からない部分がありました。 自分が「自由に生きたい」と思っている事は分かっていたのですが、「なぜ自由でいたいのか」という説明がうまくできなかったのです。自由は手段であり、得た自由を使って何をしたいのか、それが説明できませんでした。 漠然とは感じるんだけど、説明できないもどかしさをずっと感じていたのですが、デブサミの数日前、こんなツイートを見つけてやっと自分で納得できました。 @ukedchat @gapingvoid There’s one more image to this that you’re missing… creativity. @ElsiumEd pic.
Ruby東京プレゼンテーション2014に登壇していたら、同じく登壇していたMatzがいきなり「mruby 安定版 v1.0.0をさっきリリースした」とさらっと言ってました。聞いてないwww なにがなんだかさっぱり分からないので、会場に居た軽量Rubyフォーラムの中の人に話を聞いてきました。 引っ越し準備でゆっくり書いているヒマがないので、箇条書きで失礼します。 v1.0.0とはなにか？ 2014/01/10版をただフォークしたもの。開発版から変更点なし。 なにをもって安定版としているのか make testが通ってるモノが安定版。 個別のmrbgemsをインストールして、make testをテストを実行。 テストはどうやってやっているの？ make testと、コンパイル条件変更して、Windows, Linux, OSXでテストを実行。 誰がリリースしているの？ 軽量Rubyフォーラムが
新年一発目の記事として＠IT自分戦略研究所に”エンジニアとして進化し続けるには“という記事を書かせて頂きました。 自分の中でも”どうやってエンジニアとして生き続けていくのか”というのは、ずっと持っているテーマです。 定年の35歳を過ぎて数年経ち、漠然と続けて行きたいと思っても続けていくことが難しい事は明白です。 特に四十台になってくると、柔軟性や体力的に最新技術を追いかけるのが辛くなって行くという話しを良く聞きます。 そんな中でもどうやって自分がやりたいことを実現していくのか、自分なりに考えてまとめてあります。 特に残された時間が短いと思うと、焦って結果を出そうとしてしまいます。しかし、今までの自分を思い返して見ても、やはり自分を変えるには5〜10年という長さの期間が必要です。 そのため、その期間を考慮して5年後、10年後をどうしていきたいのか考えるのが大事だと言うことにやっと気がついたの
2013年も残り僅かとなったので、 振り返るために今年一年の活動をまとめてみました。 こうやって書き起こしてみると、この1年も色々なことがあったなぁと思います。 色々な所で支えてくださった皆様にこの場を借りてお礼申し上げます。 来年も、積極的に活動していきたいと思っていますので、引き続きよろしくお願いします。 制作物 ミイル – 継続開発 トレタ – 新規 wri.pe – 新規 MobiRuby – メンテナンス 講演 – 32本 1/11 テンプスタッフ アプリコンテスト：スペシャル勉強会 1/18 CROSS 2013 – スマートフォンCROSS 1/22 RIA コンソーシアム・ビジネスセミナー ハイブリッド開発のすすめ 2/4 京都でこの冬一番“Ruby”な夜〜Mobirubyのその後とRailsアジャイル開発最前線！！ 2/14 デブサミ2013 RubyでiOS/Andro
PukiWikiなどのオープンソース活動を経て、2005年からRuby on Rails関係の開発を中心に行う。2008年4月にアメリカにてBig Canvas Inc.設立、iPhoneアプリなどの開発を行う。2010年12月〜2012年9月、米Appcelerator社のテクニカルエバンジェリストとして活動。miilを経て、現在Toreta, Inc.のCTOとして活動。トレタ作ってます。 最近は、wri.peやMobiRubyの開発も行う。
“[ ]”などを個別に読む場合はleft/open bracket, right/close bracketと読んでください。 “<“はless than、”>”はgreater thanとも読みます。 Dave Thomasは”<<“を”less than, less than”と読んでいました。 “-“がdashなのかminusという話しについては、The difference between a dash and a minus signを参考にしてください。 あまり、この読み方はしないよ！とか、私はこう読むよ！とかあれば、@masuidriveまでmentionください。 [2013/11/21 14:00:00] 色々な方々にコメントを頂き追加しました。 速く・正確に読む ITエンジニアの英語 ITエンジニアの ゼロから始める 英語勉強法
LinkedInが本日、iOSの標準MailアプリでLinkedInのプロフィールを見ることのできる「LinkedIn Intro」というサービスをリリースしました。 このサービスを導入すると、メールの中で送信者の情報をインラインで見ることができます。 iOSにはメールアプリが沢山ありますが、このサービスの特徴は既存のアプリにLinkedInの機能を追加しているところが特徴的です。 通常、iOSでは「機能拡張」みたいな物を作る事はできないのですが、これはどうやって実現しているのでしょうか？ LinkedIn社のブログ「LinkedIn Intro: Doing the Impossible on iOS」でどのように実現しているのか、解説しています。 仕組みとしては、IMAPプロキシを作り、メールの本文にツールバーのHTMLを差し込んでいるそうです。 サーバ側でメッセージのキャッシュなどは
最近、大規模なWordPressのサイトの乗っ取りが発生しました。今回の原因はWordPressではなくサーバの設定に問題があったようですが、LAMPサーバの設定を正しく行うのは難しいですし、ApacheやPHP、WordPressのバージョンアップをきちんと行っていくのは、結構大変です。 自分でサーバを運用していて、セキュリティ対策をきちんとしていると言える人は、実はあまり多くないのでは無いでしょうか？プラグインなどを複数導入している場合には、それらのプラグインのセキュリティ対策を行うのはかなり難しいといえます。 そんな中、高セキュリティ環境でWordPressを運用する方法はないのか考えてみました。それにはサーバ上でアプリを動かさないのが一番では無いでしょうか？ 私のブログであれば、Voteなど動的な機能は使っていないので、WordPressのデータから静的なHTMLを生成して、Ama
7月に設立した株式会社トレタでは、フルタイムのRuby on Railsエンジニアを募集しています。株式会社トレタの設立趣旨は、代表の中村の書いたブログを読んでいただけるとご理解いただけるかと思います。 私はそのトレタで、CTOという立場でバリバリとコードを書いています。（ミイルを運営するFrogAppsとは兼任となっています） トレタでは、iPadを用いたB2Bのサービスを構築中です。このサービスのサーバサイドのコードを一緒に書いてくれるノリの合うメンバーを募集しています。 (Rubyの経験 && (GitHubで一つ以上のrepoを公開(Rubyで無くても可) || 技術系ブログを書いている))で、Railsを使っているけどもっとステップアップしたい！という方や、masuidriveとバリバリコード書いていこうぜ！と思ってくれる方の応募をお待ちしてます。 「風呂でも仕事をしてくれ」とは
wri.peのデザインは自分で作ったのですが、デザインのプロから見ると直すところは多々あるんじゃないかと思って、ミイルを一緒に作ったフォーユーの金田さんにデザインの駄目出しをしてもらいました。 まず第一に指摘されたのは、ターゲットユーザをどこに定めるかという話。エンジニアなどをターゲットにするか、一般ユーザをターゲットにするか。 wri.peは「自分用ツール」が起点なので、エンジニアなどPCやテキストに慣れている人をメインターゲットにして行こうと思っています。それであれば基本的なデザインはこの方向で良いとの事でした。 もっと間口を広くして多くのユーザに使ってもらいたい場合は、UIをがらりと変える必要があるとの事。いまのUIはなるべくシンプルにして、エンジニアなどに深く刺さることを目的にしているので、wri.peはこのUIのままで行こうと思っています。 ただトップページでは、アプリの紹介とか
ドコモはツートップ以外売る気がないとか、Tizenヤバイとかいう話しが出ているけど、ガラケー層は一定数いるんだから、いまの技術でシンプルなガラケーを再構築して出したら面白いんじゃないかなぁ。 ストレートタイプ 2.5インチカラー液晶 Bluetoothによるテザリング 200万画素(1600×1200)程度のカメラ 明るさ重視 シンプルなUI Compact HTML+Javascriptなブラウザ Webサービスでも使えるPush機能 ワンセグ・GPS・タッチパネルは無し いまのCPUは速いから、レスポンスは相当良いはず。 回線速度も今は速いから、2.5インチぐらいの画面なら、CompactHTML+Javascriptでアプリっぽいモノを作っても、そこそこ動く気がするし。 筐体は標準のモノもあるけど、3Dデータが公開されていて外部のメーカーが自由に販売できたり、気合いのある人は3Dプリ
いつも行くスタバで、すっかり行き詰まったMobiRubyのroadmapを考えつつTwitterを見ていると、木製キーボードOreeのポップアップストアが、9日間だけ銀座にオープンという記事を発見！ Oreeは木でできたBluetoothキーボードで、去年ぐらいにどこかの記事で見つけて気になったんだけど、2万円近い価格と試打できない事で二の足を踏んだままになってました。 スタバから5分程度の所で今日から限定ストアオープン！こんな偶然、ぜひ行ってみなくちゃという事でてくてく歩いて行ってみました。 東銀座の昭和通りからちょっと入ったLEAGUEという、ちょっとおしゃれなコワーキングスペース的な所でOree popup workshopが開催されていました。 OreeはMapleとWalnutの二種類から選べるのですが、自然の木を使っているので一台一台違う木目があり、このストアでは展示してあるキ
この1年間、ミイルとMobiRubyをコツコツと作っていて、個人としてWebサービス的なものを全く作っていなかったので、 気分転換 とRails4 + Ruby2.0のテストを兼ねて自分用に メモ帳サービス を作って wri.peとして公開しました。 私が使いたいメモ帳の要件は、こんな感じでした。 markdownをサポート gmailの様なアーカイブ機能 全文検索 カレンダーへのマッピング iPhone / iPadをサポート キーボードで操作ができる いままで色々なメモ帳サービスを使って見たのですが、どれもしっくりきませんでした。私はメモをtodo的に使うことが多いので、終わったタスクをアーカイブしたり、文章内に書いている日付でカレンダーに表示する機能は非常に欲しい機能でした。 「ないのなら作ってしまえ」ということでメモ帳アプリを作る事にしました。作りたいWebサービスには チャット
冬の間はiPad miniがすごく捗りました。コートのポケットに入るから、どこでもすぐにminiを取り出して使えるから。これは想像以上に便利で、地下鉄に乗ってもすぐminiでコードを書いてしまうぐらいでした。 でも暖かくなってコートを脱ぐとminiを入れるところがない・・・。春のあいだは、ポケットの大きな上着を選んできてたんですが、そろそろ暖かくなってきてTシャツだとポケットがない・・・。弾さんのようにハラに差せばいいのかもしれないけど・・・・ ということで、またカバン探し。はじめはチョークバッグ、シザーバッグとかを探したのですがよさげなのが見つからず。mini用のバッグも出てるけど、できるだけシンプルが欲しいと思いパス。 偶然通りかかった、吉田カバンのお店でちょうど良いサイズのショルダーバッグ発見。ちょっと小さくて閉まらないけど良い感じ。でも普段はバックパックを背負うのでショルダーバッグ
TwitterやFacebookでつながっている人と勉強会などで会うこと多いんですがネット上で親しくてもリアルな顔を知らなくて、帰宅後にタイムラインを見て会ったことのない人が同じイベントに参加している事を発見してがっかりする事があります。 iPhoneのカメラを通してみると、みんなの頭の上にTwitterのアイコンが表示されるアプリなんかがあると良いんですが、さすがにそれは技術的にムリです。 Pokenが見た夢? 数年前にPokenという、キーホルダーサイズのデジタル名刺的なデバイスが出ましたが、タッチしたあとにPCにつないだりするのが面倒で、いつの間にか電池が切れてそのまま持ち歩かなくなってしまいました。 Pokenの様にタッチするのではなく、Nintendo DS/3DSのすれ違い通信のような感じで、近くで同じデバイスを持っている人を自動で認識して記録したり、友達申請を出せるようなデバ
「PukiWiki の開発プロジェクトの再建案 – Sarabande.jp」を読み、プロジェクトの発起人としてちょっと書いてみることにしました。 私もPukiWikiプロジェクトが止まっている事は前から認識をしており、どきどき他の方からも相談を受けていました。 未だに多くのユーザもいますし、強力な代替がないのでPukiWikiの再出発を願う人も多くいるとおもいます。しかし、私ももう8年ぐらいPHPでコードも書いていなく、私自身はPukiWikiに手を入れるモチベーションが出てきませんでした。 このPukiWikiの問題は二つの側面があります。 PukiWikiというアプリの停滞と、PukiWikiプロジェクトの崩壊です。 前者は最近のPHPでは動かないという現実的で致命的な問題があります。またスパムに耐性がなくロボットに広告などの書き込みを許してしまうという運用上の問題もあります。いまP
昨年の3月から開発を始めたMobiRubyは、まだ開発途中で多くの方々に使って頂ける状態ではないにも関わらず、福岡Ruby大賞のポストPC賞と、日本OSS奨励賞を頂くことが出来ました。多くの方が応援してくださった事で、受賞できたのだと思います。ありがとうございます！ 当初の予定より時間は掛かっていますが開発は順調に進んでおり、ObjCとCocoaを使えれば何とかiOSのアプリを書けるようになりました。開発をこのまま進め、ObjCやCocoaの知識がなくてもRubyを使って、気軽にiOSやAndroidのアプリ構築を行えるツールにしたいと考えています。 MobiRubyは私の趣味であり、RubyでiOS/Androidのアプリが書ければ幸せだなぁというプロジェクトですが、それと同時に海外でも多くの人に使われ、自分の名刺代わりになるプロジェクトにしようという気持ちもあります。 しかし、世の中に
最近、mrubyのIssuesを英語で書くのが厳しく、やっぱり英語は勉強しなきゃなと日々痛感しています。 勉強するにしても普通の英語とは違うので、Issueを英語で書くためにどれぐらいの単語力が必要なのか調べてみました。 GitHub上のmrubyとnodejsのIssuesをダウンロードして形態素解析をして、単語の頻度をグラフにしてみました。 ものすごく偏っていることがわかります。 ここから1000だけ切り出してみます。 これを見ると3-500でほとんど部分をカバーできそうです。固有名詞もあるからもっと少ないはず。 これをベースにして「300語で書くオープンソースの英語」とか出来ないかな？ あとは、Phrasal verbs(get into, put onみたいなヤツ) なんだけど、代表的な物を公開しているリストないかな？それもランキングできると面白そう。 なお、この単語数は形態素解析
次のページ
このページを最初にブックマークしてみませんか？
『クローゼットがいっぱいになったので壁にハンガー掛けを作ってみた』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
