You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時?それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※ このお話は ( おそらく ) フィクションです。実在の人物や団体とは関係ありません。 前書き 中規模程度のサービスを Serverless 構成の SPA をパイロットリリースしました。具体的なサービス名等は紹介できません ( おそらくフィクションなので ) が、筆者が3ヶ月間でやってきたことを殴り書きして行きます。 基本的にはリリースまでに必要となった材料 ( 参考にしたドキュメントやサイト ) を重点的に紹介していくだけですが、同じような境遇の方々の手助けになれば幸いです。 筆者のプロジェクトイン時スペック 社歴3年程度 主にバ
僕はプログラマをしていて、数千万行以上の規模で10億ユーザ以上が使うようなプログラムの開発にもかかわっていたりしたけど、そういう仕事環境で「(ある何かが)オブジェクト指向かどうか」という議論をほとんどしたことがない。デザインのレビューでもAPIが十分シンプルかどうか議論にはなるけど、そのやり方がオブジェクト指向かどうかなどという観点でものを見る人はいなかった。日頃のコードレビューでも、やるべきことが普通にわかりやすく行われているかという観点でコードを見るのが普通で、オブジェクト指向ではどう、ということをいう人はいなかった。 一方でプログラミングの入門書などをみると「オブジェクト指向とはなにか」という説明に多くの分量が割かれていて、オブジェクト指向というものが、なにかまるである時点で悟りを開くように理解すべきものであるかのような解説がなされていることがよくある。しかもその解説が哺乳類と犬と猫
全国のGoogle Apps Scriptファンの皆様こんにちは Apps Scriptガチ勢の大橋です。 今年でGoogle Apps Scriptアドベントカレンダーも3年目になりました。 年々人は減っている気がしますが、BigQueryとの連携など他のアドベントカレンダーに名前が出ることが増えてきて、嬉しい限りです。 さて、ちょいSlack BotをGASで作る機会があったのでSlack API周りをGASで扱うためのLibraryを作りました。 今回はこのLibraryとそれを使って作った会議予約Botのサンプルコードについて書いていきたいと思います。 なお知らない方も多いので書いておくと、GASのLibrary機能は丁寧に作ると補完が非常に効くようになり、開発効率が10倍以上変わります。 Libraryについて詳しくは以下の記事を見て下さい。 2012年Google Apps S
白ヤギの開発者の森本です。 白ヤギでは Go 言語でニュース記事のキュレーションをする カメリオ API というサービスを開発しています。約1年2ヶ月前、Go を使って開発し始めたときに当時調べた内容を整理して以下の記事を書きました。 Go言語で API サーバーを開発する 1年以上に渡り開発を継続してきて変わったこと、変わってないことなどをざっくばらんにまとめてみます。たまたま過去の記事のはてブコメントを見返していて 以下のコメント を見つけました。 最近 golang 導入事例増えて来たけど、導入後一年くらいのメンテナンスフェーズな事例について聞いてみたい。継続的デリバリーみたいなの。まだ早いのかな? まだまだメンテナンスフェーズにはなっていなくて現在も活発に開発中ですが、継続的デリバリーについて白ヤギでは特別なことをしてなく、ansible を使ってデプロイしているのみです。Go 1
ユーザーインターフェース(UI)- どこかで聞いたことはあるしなんとなく想像は出来る。”このアプリのUIはイケテル”や、”UIデザイナー募集”など、最近ではテクノロジー系の記事や、デザインに関する話の中に頻繁に出てくるこの言葉。 しかしちゃんと言葉で説明してみてと言われると意外と難しい。 興味はあるけどはっきりとはわからない・わかっているつもりだけどもう一度復習したい・現状はわかっているからこれからのUIついて知りたい。 そんな人たちに向けて ユーザーインターフェースの歴史良いUIと悪いUIの違いUIのこれからという3つのセクションに分け、インターフェースの本質をまとめた。 1. ユーザーインターフェースの歴史そもそもインターフェースってなに?そもそもユーザーインターフェースの「インターフェース」とはどういう意味なのだろうか。「境界面・接触面」などと訳されるこの「インターフェース」という言
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか? どの例外をキャッチし、どの例外を伝搬させればよいだろうか? 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか? 例外をどういう単位でラップさせるのが良いだろうか? 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
4/7 18:00頃にLINEの「BOT API Trial Account」が無償提供されたと聞いてとりあえず触ってみたら出来る事は結構少なかったので勢いで全て試してみた。 [追記 4/14 9:28] Facebook Messenger Platform BETAでできる全ての事を試してみた(LINE BOT APIとの比較あり)も合わせてどうぞ。 [追記 4/9 11:49] 現在、巷で話題のLet's Encrypt問題以外でコールバックがコールされない問題があるらしいのでご注意を。 [追記 4/9 12:49] 上記の問題は解決した模様。 まずはアカウント登録 ※先着10,000名って少ない気がするけどまだ登録できるって事はそんなに人気ないのかな。 https://business.line.me/ja/products/4/introduction BOT API が利用開始
(編注:2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか(私がしたことを見てください)。 リスティクル(箇条書き形式の記事) を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
1.0.0 がリリースされました。やりましたね。 僕の観測範囲内に見えることが増えてきたので、興味本位で少しずつ触っています。 まず、ブラウザだけで試せるチュートリアルが大変素晴らしいので、Kotlin が肌に合うかどうか確認するといいですよ。 Kotlin Koans js で実装されたエディタなのにシンタックスハイライトだけでなく、入力補完がガンガン効くので凄く良い。 僕の理解 大体 3 日くらいかけて言語仕様やマニュアルの類を読みながらチュートリアルをこなした結果、 Kotlin は 安全な次世代の Groovy である という理解に到達しました。 僕が Groovy に対して持っていた不満は、大体以下の通り。 ランタイムがデカ過ぎる groovy-all-2.4.6-indy.jar が 6.5M バイトコードエンハンス等の危険な黒魔術がカジュアルに動く 型がありそうで、実は殆ど
XAML と C# を使った Windows ストアアプリ(LOB)構築のためのtips Prism 4.5 & Kona project 等のご紹介
みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります(参照)。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ
unassert - encourage reliable programming by writing assertions in production
こんにちは!クックパッド編集室メディア開発グループ長の @yoshiori です。 このまえ夏の技術職インターンシップの前半の開発講義・課題部分が終わったのでさっそく公開しちゃいます! ちなみにこのインターンの対象者はプログラミングはわかるし自分で(授業とかではなく)コード書いている人なので超初心者向けでは無く、少なくともひとつ以上の言語でプログラミングが出来る人向けです。 一日目 TDD + git 編(@yoshiori) 講義初日なのでまずは簡単に肩慣らし & 開発の基礎の部分として TDD と git で始めました。 git については軽く説明し TDD は基本のテストファーストで進めて行きました。 ちゃんと何かをするたびにテストを実行し、メッセージを見れば次にすることが分かるというのを体験してもらい、GREEN が良くて RED が悪いのではなく、GREEN を想定しているのに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く