Creating an realtime collaboration tool: Agile Flush - .NET Oxford
![デザイナーとエンジニアの良い関係](https://cdn-ak-scissors.b.st-hatena.com/image/square/7cd56ea3179993fd8cd1783b1ea782faa9f714e9/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F9efb36604c3b013268184ae983a8a7e9%2Fslide_0.jpg%3F3883129)
こんにちは!はてなでスマートフォンアプリを開発している id:cockscomb です! 先日リリースした はてなブログのAndroidアプリは、Android 5.0 Lollipopに対応し、Googleの新しいデザイン言語 Material Design をいち早く取り入れるなど、はてなが提供しているAndroidアプリとして様々な面で新しいものとなりました。まずは、Androidスマートフォンをお使いの皆さまにご利用いただけたら幸いです。いまならキャンペーンも実施中です。 はてなブログAndroidアプリ さて、この新しいアプリですが、その開発においてもモダンな手法を多く取り入れています。本記事ではその開発について、順を追ってご紹介します。 企画・プロトタイピング はてなブログAndroidアプリの開発に着手したのは、ちょうどGoogle I/Oのキーノートが行われた、今年6月26
こんにちは!ChatWork CTOの山本です。 チャットワークのバックエンドをPHPからScalaへの切り替えることを決断し、現在は移行に向けての大プロジェクトが進行中です。 バックエンドはScalaにしていく。じゃあフロントエンドはどうするの?ということで、今回はチャットワークのフロントエンド開発における今後の戦略を書いてみようかと思います。 現在のフロントエンドにおける課題現在のJavaScriptコード量は、ざっと5万行ほどになっています。(OSSライブラリ、言語キーなどを除く。たぶん大規模・・ですよね?) 約5年前の開発スタート時より、素のJavaScriptとjQueryをベースにゴリゴリと書き重ねられ、これぐらいのコード規模になったソースコードはご想像通りメンテナンスコストがかなり高くなってしまっています。。。 バックエンドの刷新に伴い内部APIも一新されるため、どうせ大幅に
こんにちは。ライターの伊丹松です。最近喉が痛いです。9月10月に風邪を引かない人って逆になんなんでしょうね。 さて、最近では「モバイル・ファースト」などと言われるように、ますますプライオリティが高まっているのがスマホサイト制作。 しかし、PCサイトに比べてどうしても縦長になってしまうため、キャプチャが必要な場面でも一度に全画面を撮ることができません。スクロールして撮った複数の画面写真を後からPhotoshopで繋げて…という作業経験がある方も多いのではないでしょうか。 デザインチェック、デバグ、構成書・指示書への貼付けなど、キャプチャはさまざまな場面で必要になります。ちょっとした作業ですが、ページ数が多いサイトなどでは、トータルでみればけっこうな作業量になります。 そこで今回は、そんなキャプチャ作成作業の手間を解消してくれるアプリを紹介したいと思います。 WebCollectorの紹介 他
非デザイナーエンジニア(Rubyist)の私が、一人でこんなWebアプリを作ってみました。 まだβ版ですが、Pocketやfeedlyの未読コンテンツの中から、 重要度が高いものだけをリマインドしてくれるサービス「Reminderr」です。 Reminderr:http://www.reminderr.me/ 要するに、私自身のPocketとかRSSがカオスになっているので、 その中で重要なものだけ教えてほしかったので、 自分で作っちゃえ!って思って作りました。 そのときに使った便利ツールたちをまとめておいたら便利そうだったので、 今回使ったもの+αを全てまとめてみました。 紹介するツールたちを駆使すれば、 非デザイナー&デザインセンス0の私が、 1週間程度でこれくらいのアプリをリリースできるので、 他のエンジニアにも便利なツールがいっぱいあると思います。 Bootstrap系 Boots
技術部の高井です。 最近、日本でもマイクロサービスという言葉が流行しつつあります。 今回は、なぜクックパッドがマイクロサービスを選択したのか、また実際にどのようなやり方をしているのかということを紹介します。 Conwayの法則 ここ数年の間、クックパッドはレシピの投稿・検索サービスから「食を中心とした生活のインフラ」として事業領域を拡大しつつあります。海外レシピサービスの買収による海外展開は、単なる金銭的な関係にとどまらず、人的・技術的な交流も含めて本格化しつつあります。また、「モバイルファースト」を標語とするモバイルアプリケーションへの取り組みも加速してきました。 事業領域の拡大やグローバル展開、モバイルファーストといったビジネス要求の変化に応じて、会社の組織構造も変化しています。そして、Conwayの法則 として知られているように、組織構造とソフトウェアアーキテクチャには密接な関係があ
モバイルファースト室の @slightair です。 先ほど、デザインをリニューアルしたクックパッドiOSアプリ 6.0.0 をリリースしました。 https://itunes.apple.com/jp/app/kukkupaddo-no.1reshipi-jian/id340368403?mt=8 この記事では、どのようにして新しいデザインをiOSアプリに適用していったのかを紹介したいと思います。 新しいアプリの画面 スクリーンショットを見ていただければわかるように、全体的にフラットな印象を与える画面に変わりました。 トップ レシピ詳細画面 サイドメニュー この記事で全ての画面を紹介することはできませんが、ぜひダウンロードしてお手持ちのiOS端末で触ってみてください。 新デザインの適用 基本的には、画面デザイン案をもらい、既存のアプリを修正して少しずつ適用していく形で進めていきました。
先日の土曜日に、はてな主催で行われたイベントで現在のチームで行っているフローを紹介しながらデザイナーがXMLを書くと良いことについて発表してきました。 ちなみにXMLというのはAndroidのレイアウトを制御するための言語です。 なぜデザイナーがコーディングまでやるといいと思っているのか、感じていることを少し書きます。 カンプは実装と違う カンプと実際に動くものとは全然違います。例えばタイトルと本文が動的に入るようなアプリを制作しているとします。とすると、自分が想定しないくらい長いタイトルをつける人がいれば、めちゃくちゃ短い本文を連続して書く人もいるかもしれません。どんな文章が入ってもいい感じに見せたいのですが、PhotoshopやIllustrator上だと想像がしずらいです。 また、カンプでボタンのon/offのパターンを作った場合も同様です。実際使ってみると色の変化が大げさだなとか、
http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
これだけモデリングとは 「これだけモデリング」とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です(山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き)。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング(slideshare) これだけモデリングとは、 誰が? ー 情報システム部門の
mozaic.fm #7 RESTや#mozaicfm REST を聴いての感想、それから「Web+DB vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。 REST設計について WebAPIを設計するうえでRESTが重要であることは周知のとおりである。 “Constraints are liberating”「制約は自由をもたらす」 @t_wadaさんがおっしゃっているように、RESTを前提にすれば、「アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる」という大きなメリットが生まれる。 しかし、相変わらずリソース設計やらインターフェース設計やらで悩んでおられる方も多いと聞く。 その一方で個人的には適切なフレームワークを使えばREST設計で悩まなくてもよいはず(※3)という思いもある。 インターフェース設計な
弊社では毎年インターンを受け入れているのだけど,いまもインターンが来てて,テスト先に書きたいけど油断すると先に実装を書いてしまう,とか話してた. 個人的には,テスト先に書くのが大事というよりかは,意識して仕様を先に考えるのが大事だと思っている.テストを先に書くと,先に仕様を考えざるを得ないので,良いスタイルが身につく. 僕がよくやるのは,関連しそうなクラスの絵をひと通りノートに書いてみて,その図だけで,うまく動くことを説明できるくらい考えてみる.その時点でおかしかったら,コード書いてもおかしくなる.ノートに方眼ついてるとクラス図書きやすい.UMLとかじゃなくても,自分で見て分かるくらいでもいいと思う. 紙でうまくいったら,外部仕様だけソースコードに書いてみる.クラス名と,メソッドの定義と,メソッドの上くらいに,ひと通りコメントでも書いてみて,この関数はこういうことをするんです,こういう引数
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
ウェブデザインについてまったくわからない頃によく見て勉強してた資料群です。+いくつかの自分で作った資料 SlideShare 色彩センスのいらない配色講座 色相、明度、彩度で色を説明できるようになる。 ベースカラー、メインカラー、アクセントカラーで配色を説明できるようになる。 その上で、あまり間違いのない色の選び方がわかるようになる。 ノンデザイナーのための配色理論 最後に紹介されているこのツールがベースカラー、メインカラー、アクセントカラーを決める上で便利。 ウェブサービスの企画とデザイン 僭越ながら明治学院大学で講義した時に作った資料。 なんとなくウェブサービスを作るときの流れとか感じてもらえたら幸いです。 かんたんキレイなウェブデザイン 僭越ながら勉強会 (UT Startup Gym) 用に作った資料。 なんとなく CSS フレームワーク、グリッドシステム、レスポンシブデザイン、ウ
SNSを眺めているとクライアントからの無茶苦茶だったり意味不明な要求への愚痴をよく目にする。 居酒屋で同業の人と飲んでいても、キツイ要求についての話が出ることが多い。 それは多くの場合「プロとして、クライアントの無茶な要求に応えてやったぜ。」みたいな話が多いのだけど、ぼくは少し違和感を覚える。 クライアントは、制作者よりも制作についての知識が希薄であることが多い。そのため、その実装によってどれだけのコストがかかるのか、費用対効果はどうなのか、ユーザビリティやアクセシビリティへの配慮、情報設計は破綻しないのか、メンテナンス性が大きく損なわれることはないのか、などを考えられるベースがない。 無茶な要求はそのために生まれることが多いけど、それを鵜呑みにしてはプロとして失礼にあたると思う。 プロとして依頼された以上、クライアントの意向は汲みながらも、制作者が持っている知識を最大限に活かして提案をし
めちゃくちゃなタイトルですが、表題のとおりです。 本日、SHOMEI DESIGNというメールの署名のビジネス向けテンプレート集サービスをリリースしました。 リリースの作業ログ的な記事を書いてみようと思います。 完全に自己満足記事なのであしからず……。 なぜつくった? 新卒のころ、メールの署名をつくるために、ひたすらググったり、先輩社員からくるメールの署名をみたり……と、だいぶ時間を浪費した記憶があったからです。 私と同じような人がいるかどうかは分かりませんが、そんな人たちのためになればと思いつくりました。 たとえば、「署名」でググって上にくるこのまとめですら、1,600,000view以上もの閲覧数です。 需要はあるだろうという判断でした。 正直私はチャットワーク万歳な人で、コミュニケーションはすべてチャットワークに集約されればいいと思っています。 ただ、世の中からすぐにメールがなくなる
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の3つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から: なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
昨今アプリ開発を行う上でのUIアニメーションやデザインの重要性が非常に高まってきました。一方でアプリの質を保ちながら開発スピードを上げるためには、様々な工夫が必要です。 今回はDeNAの開発者である吉田正史さんに、開発事例をもとにどう現場の課題を解決し、効率を上げていったのかなどについて寄稿していただきました。 by 馬場美由紀 (CodeIQ中の人) 話に出てくるアプリの紹介 DeNA吉田です。 今回ご紹介するのは、実際に下記のアプリを開発する現場で直面した課題です。 RabbitCam RabbitCam Rabbit cam(ラビットカム)はアニメーションするスタンプやBGMを選び、合成して動画を作成するアプリです。 非常にかわいいスタンプをより、可愛くする細かい動きや、おしゃれに仕上げるための動画に対してのフィルタの色味など細かい調整を重ねました。 QuizNow QuizNow
僕はコマンドラインで使うシェルスクリプトを書くことがけっこうあるんだけど、インターフェイスというか呼び出し方はとても大事だと思ってるので、そこにわりと時間をかけて考えるようにしてる。実装はいつでも変更できるけど呼び出し方を変えた時は利用者にも変更を強いるので、できれば最初から良い設計で作りたいと思っている。 そこで、僕がシェルスクリプトのオプションとか引数とかの仕様を決める上で注意していることをまとめてみた。シェルスクリプトや、その他コマンドラインのツールを作るときに参考にしてほしい。 シェルの種類は bash や zsh を想定してるけど、実装によらない話なのでどんなシェルでも使えると思う。 エラーの時に Usage (使い方ヘルプメッセージ)を表示するのはやめる エラーになった時に Usage (使い方ヘルプメッセージ) を表示するスクリプトがあるけど、やめたほうがいいと思う。例えばこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く