Electron で Slack 風UIの HipChat クライアントを作っている話 - ぐだぐだ言ってないでコードを書けよ、ハゲ。
この記事は Electron Advent Calendar 2015 - Qiita の1日目の記事です。 ここ最近作っているアプリについてまとめる。 アプリについて HipChat をギョームで使っているが、巷では Slack が流行しており、乗り換えたい願望が高まっている。 しかし乗り換えにはコストの面でハードルがある。 そこでSlack風味なHipChatクライアントがあれば面白いかもと、作っている。 ただ作るだけでは面白くないので、未経験だった技術(Electron, AngularJS, gulp)を使っている。 まだまだいろんな機能が足りてないが、ちょっとメッセージを送る程度には使える。 HipChat 公式クライアントは最後に開いたRoom(SlackでいうところのChannel)がデバイス間をまたいで微妙に同期する仕様。 別PCで少しRoomを開き、元のPCで見ると開いて
リーン・スタートアップとワインと僕 - ぐだぐだ言ってないでコードを書けよ、ハゲ。
前にリーン・スタートアップとシゴトの話を書いたけど、今回はプライベートな話。 リーン・スタートアップ リーン・スタートアップ 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二出版社/メーカー: 日経BP社発売日: 2012/04/12メディア: 単行本購入: 24人 クリック: 360回この商品を含むブログ (92件) を見る 前に書いた記事から抜粋。 リーン・スタートアップではサイクルタイムを短縮することが奨励されている。 サイクルタイム＝いわゆるPDCAのことだ。 要約すると、製造業（自動車）で一人が一工程だけを担当するより、 一人が全工程を担当してしたほうがムダが少なく改善につながったという話。 どうやってプライベートに活かすか 僕はいわゆる「新しいもの」が好きだ。 マーケティングでいうところの、アーリーアダプターというやつかもしれない。 （このへんの用語はコチ
リーンスタートアップとスクラムと僕 - ぐだぐだ言ってないでコードを書けよ、ハゲ。
リーン・スタートアップ読んでたら昔のことを思い出したのでそのへんを書いてみる。 リーン・スタートアップ リーン・スタートアップ 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二出版社/メーカー: 日経BP社発売日: 2012/04/12メディア: 単行本購入: 24人 クリック: 360回この商品を含むブログ (92件) を見る リーン・スタートアップではサイクルタイムを短縮することが奨励されている。 サイクルタイム＝いわゆるPDCAのことだ。 要約すると、製造業（自動車）で一人が一工程だけを担当するより、 一人が全工程を担当してしたほうがムダが少なく改善につながったという話。 これ読んでいて開発フローの遷移が頭に浮かんだ。 スクラム以前 数ヶ月単位でリリースしており、リリース後は打ち上げが行われていた。 リリースのタイミングや半期の評価のタイミングでプロジェクトの良
SEO の話でいつもモヤモヤする - ぐだぐだ言ってないでコードを書けよ、ハゲ。
まずはじめに断っておくと、僕は大したサイトを作ったことがない。 それでも SEO について書くのは、しばしばネット上に議論になんだかモヤモヤするからだ。 こう書くと SEO 対策になる こういうキーワードを散りばめるといい コンテンツが優れていることこそが SEO だ！ みたいなのばっか。 「検索ロボットに合わせてサイトを作るのか？」ってこと。 SEO という言葉に振り回されすぎていると思う。 振り回されていない人もいるみたいだけど、ごく少数だろう。 ニコニコ動画を設計するときというのは、いかにSEOを無視して、いろんなネット業界の常識的なものを無視してサイトを作ることができるかということにすごい命をかけたんです。 「いかにネットの常識を無視するか」 川上量生氏がニコ動をつくったときの”3つの発想”がすごすぎる より 自分の考えを書くと、Webサイト VS 検索ロボット の構図ではなくて、
Rebuild.fm のゲスト出演回数ランキングを勝手に公開した - ぐだぐだ言ってないでコードを書けよ、ハゲ。
はじめに 僕が技術系 Podcast にハマるきっかけとなった Rebuild.fm 。 （もう広まってるけど）Rebuild.fm をより多くの人に触れてほしくて、ゲスト出演回数ランキングを勝手に公開してみた。 http://rebuildfmranking.herokuapp.com/ つくった感想 まだまだ Ruby も Rails も全然だけど、スクレイピングやキャッシュを学ぶきっかけになった。 前にも書いたけど、学習サイクルの好循環が生まれているなあと思う。 参考にした情報 Chartkick Railsでmemcacheを使ってobjectをキャッシュ - Qiita Nokogiri を使った Rubyスクレイピング [初心者向けチュートリアル] - 酒と泪とRubyとRailsと 最後に 僕自身は英語のエピソード9以外は3,4回ずつ聴いているくらいの準ヘビーリスナーで、@n
次の staticおじさんは僕やあなたかもしれない - ぐだぐだ言ってないでコードを書けよ、ハゲ。
今日のstaticおじさんの名言「VisualSourceSafe 2005以降って使いにくいからソース管理やめたんだよね。最新のソースはファイルサーバにzipで圧縮しておいておいて」— だいすけ (@daisuke774) 2014, 4月 9 とある福井のstaticおじさん - Togetterまとめ このまとめ読んだ。 ヒドい職場だよなー オブジェクト指向使えないとかありえないよなー ソースコード管理しないって意味分かんないよー って感想がほとんどだと思う。 でも、職場に何かを導入したという人はそれほど多くないのではないか、と思う。 たまたま staticおじさんの職場環境よりも進んだ職場に入ったというだけ。 それって staticおじさんと何が違うんだろう？ 新しい技術に、抵抗するか or 黙って受け入れるかの違いだけじゃないか。 （往々にして、黙っていた人たちは導入後に文句を言
Ruby を始めて2日目の僕が驚いたこと - ぐだぐだ言ってないでコードを書けよ、ハゲ。
photo credit: Kmark via photopin cc Ruby を初めて 2日目。 Railsチュートリアル第4章で Ruby の基本的な使い方を学んだ。 Ruby を使って驚いたことがいくつかあったのでまとめておく。 （プログラミング経験はそれなりにある。C# や JavaScript, PHP など） Rubyist の方は、初めて Ruby に触れたときのことを思い出すきっかけに。 非Rubyist の方は、Ruby に興味を持ってもらえるきっかけになれば。 なお、いくつかのコードは Railsチュートリアルから抜粋している。 end はあるけど begin しない 多くの言語では関数やブロックを中括弧で括る。 Pascal 系言語では begin 〜 end で括る。 Ruby では begin なしで急に end が出てくる。 if string.empty?
LINE の動向による未来予測 - ぐだぐだ言ってないでコードを書けよ、ハゲ。
【LINE】LINE、グローバル市場での更なる成長に向け、「BEYOND LINE」をテーマに3つの新サービスを発表 業界に激震走る。本日のLINEの発表でネットの世界はどうかわる? | More Access! More Fun! LINE のニュースによるワクワクが止まらない。 このニュースによって起こるかもしれない未来の話を3つ書く。 当たったら後でドヤする。 未来予想図Ⅱ ~VERSION'07~ DREAMS COME TRUEJ-Pop¥250provided courtesy of iTunes デザイナーの価格上昇 参入障壁の低いスタンプのオープン化により、 企業からデザイナーへの依頼が急増する。 特にクラウドワークスやランサーズといったクラウドソーシングでは顕著だろう。 これにより、デザイナーの人手不足により、もともとニーズのあったロゴやアイコンなどのデザイン単価が上昇す
残業するなら勉強しよう - ぐだぐだ言ってないでコードを書けよ、ハゲ。
最近チームメンバーによく言っていることがある。 さすがにタイトルの言い回しだと角が立つので、 「残業するくらいならその分の時間を勉強に当てない？」 というくらいの感触で話している。 残業を非推奨する理由 自分が残業しようと思ってしまうときは、大体次のどれかだった。 技術的なことでハマって実装が進まなかったとき 会議が上手く進まず、集中力がすり減った後で実装するとき 精神的にやる気になれずに日中だらだら実装してしまったとき 結果は見えている。 この状態のまま続けてもうまくいかない。 photo credit: marsmet473a via photopin cc 本当は体を動かすとか全く関係ないことをやって頭を切り替えたほうが効率は良くなるんだけど、ついつい「自分のミスを取り返したい！」という気持ちが出てしまう。 その結果「残業」という選択をしてしまう。 これは「チームにとってマイナス」に
僕らが技術的負債と呼んでいるもの - ぐだぐだ言ってないでコードを書けよ、ハゲ。
photo credit: miguelavg via photopin cc 技術的負債は少しずつ蓄積されていきます。 技術的負債が何を指すのか、相手によって一部しか理解されないことがあるので、まとめてみました。 基本的にシステムの「品質」を構成する要素を逆に捉えただけなので、ここでは品質の構成要素をまとめます。 参考：アプリケーション アーキテクチャ ガイド - 品質特性の章 by Microsoft 設計 システム構造 全体が一貫性のある構造になっているか。 たとえばUIにビジネスロジックが入り込んでいないか。 保守のしやすさ 機能拡張しやすい構造か。 また、バグを修正しやすい構造か。 たとえば必要に応じて必要なモジュールのみを修正すれば対応できるようになっているか。 流用しやすさ 他のシステムにも流用しやすい構造か。 たとえばそのシステム以外にも同じUIコンポーネントをそのまま流用
エンジニアをデスマに巻き込むときにやるべきこと・やるべきでないこと - ぐだぐだ言ってないでコードを書けよ、ハゲ。
下の記事を読んで、大変共感しました。 エンジニアとして「頑張る」ということ - 銀の人のメモ帳 実際は、様々な状況でデスマや残業をせざるを得ない事が多々ある。会社として頑張らなければならなかったり、金銭的なものであったり、色々な事情がある。 そうなったら僕は、残業もするし、デスマもするし、炎上の火消しもする。 この辺りを読んで、 エンジニアをデスマに巻き込むときにやるべきこと・やるべきでないことを書きます。 やるべきこと 正直に事情を説明する 真っ当なエンジニアは自分が抱える問題を共有し、エンジニア同士で解決を図ります。 エンジニアが解決できない問題は適宜マネージャーに相談します。 仮にそれがエンジニアの力不足によるものだとしても。 正直になることでチームは前に進みます。 マネージャーもエンジニアのこのような行動を望んでいるはずです。 それなのにマネージャーがエンジニアに対して正直でないと
ITエンジニアの評価制度をどげんかせんといかん - ぐだぐだ言ってないでコードを書けよ、ハゲ。
私は宮崎出身ではありません。 目標管理シートドリブン開発はくそ - razokulover publog を読んで同意しました。 目標管理シートについて、私も感じる問題点と対策を挙げておきます。 （重複意見は抜いておきます） 事前にコミットするために目標の変更が利かない 表題のとおり。 ちょっとフィクションの話を。 半期の初めに目標設定をしました。 仮に「Ruby を業務で使えるレベルになる」とでもしましょう。 （この時点で別の問題もはらんでいるが、それは後述。） 少し勉強を重ねた1か月後、 Ruby が陳腐化しました。 実際 Ruby という言語自体のような手堅い目標であればいいでしょうが、 今さらそんな目標設定することはないでしょう。 登場したばかりの新しい技術を試してみることのほうが多いと思います。 しかしその技術は陳腐化する可能性があれば、 1か月後にもっといい技術が出てくる可能性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
