アプリクライアントがリソース指向なサーバAPI設計に期待すること - Qiita
酔いどれ設計ナイト2019 - connpassの発表資料です。 イベントのテーマ 「DB設計とAP設計をつなぐナニカ」 ということでこの記事では、アプリケーションサーバの利用者であるクライアントの視点から、どういう構造が嬉しいのか語ります。 自己紹介 iOSアプリ設計パターン入門という本の前半で、「設計とは何か」という主語の大きい話をしたり、GUIアーキテクチャの40年の歴史をまとめたりしました 題材をSwiftに絞っただけで、内容としては他プラットフォームにも通用する感じのやつなのでよかったらおひとつどうぞ Qiitaだと、お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiitaという記事がよく読まれてます 議論の前提 今回の議論にはいくつかの前提があります。 クライアントチームとサーバチームが充分に協調し
ベロシティを目標にする危険性について学んだことをアジャイルサムライ風に振り返ってみた - Grooves開発ブログ
こんにちは、Forkwell事業部の中の人です。 本日は、つい最近 Forkwell Jobs の開発現場で起きたエピソードについてご紹介します。 きっかけはあるメンバーの一言でした。 「複数メンバーの加入から1ヶ月以上がたった、ベロシティもかなり安定してきた。よし、ここらでおれたちのベロシティをあげて、ビジネスサイドの連中をあっと言わせてやろうぜ！」 この一言で息巻いた我々は、ベロシティをあげることを目標に設定し、ビジネスサイドのホワイトボードに ◯pt / 10pt のような数字を書き加えました。 しかし、すぐに色々な現場を経験してきた他事業部のエンジニアの面々から、ベロシティをあげることを目標にすることには弊害があることを教わることになりました… ベロシティを目標にする弊害 目先のポイントを増やすためにとりあえずリリースして残タスクを先に積む事案が発生、後々の作業が滞る 目先のポイン
設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
ソフトウェア開発における 「設計」と「パフォーマンス」の相互作用 / Interaction Between Design and Performance on
Software Development - Speaker Deck
設計Night2018の資料です https://connpass.com/event/104821/
東京証券取引所で、幻となった「初代証券取引システム」の提案書・仕様書を見せていただいた 【歴史・情報処理・MARS】｜阿部タツキ/料理カメラSnapdish
東京証券取引所で、幻となった「初代証券取引システム」の提案書・仕様書を見せていただいた 【歴史・情報処理・MARS】 先日、祖父の三回忌だった。 祖父が亡くなったあとに書きかけた文章がフォルダに残っていた。 祖父が関わったと思われる証券取引所のシステムについての文章だ。いつか誰かの参考になるかもしれない。世に出しておく。 ---- 祖父が亡くなった。 隣接した家に住んでいたので、よく昔の話や仕事の話を聞かせてもらっていた。 コンピューター技師・研究者だった祖父の仕事のうちいくつかは、記録が残っている。 穂坂 衛は、日本の技師・学者。東京大学名誉教授。 【Wikipedia 穂坂衛】 その仕事一覧のなかに東京証券取引所のシステムについての記載があるのだけれども、他の仕事に比べて言及が少なく実際にどんな関わりがあったのか少し気になっていた。 ググってみると、東証が2016年の夏に「東京証券取引
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
見積もりについて勉強したことを色々スライドにしてみた - だいたいよくわからないブログ
見積もりについて思ってることとかをまとめてみました。 マネージメントの実戦経験というよりソフトウェア開発手法について学んだ結果のアウトプットみたいなノリでみていただければ幸いです。 社内勉強会で話したので会社のスライド使ってますが、会社が今こうというわけではなく一般的な話にとどめています。（あとstudy_lean_agileっていう名前の勉強会なんですが、このスライドはリーンもアジャイルもあまり意識していません） 前半は自分なりの考え方、後半は具体的にはこうしたらいいんじゃないかと思っていることという風に分けています。 誰のための見積もり・何のための見積もり part1 from matsu_chara Matsubayashi www.slideshare.net 誰のための見積もり・何のための見積もり part2 from matsu_chara Matsubayashi www.s
SmartHR が定期メンテナンスを始めた理由とやめる理由 - SmartHR Tech Blog
SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。
DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました（前編）
1月10日に六本木ヒルズにて、James Coplien氏をお招きしてLean Architectureに関する勉強会を開催しました。UUUMさんに大変素敵な会場を提供頂き、スタッフ含めて40名前後の参加者が集まりました。 このブログでは、当日の翻訳担当を務めた@remoreと@ganchikuが、当日の翻訳内容から抜け落ちた部分の捕捉を含めて、内容のアウトラインを簡単に振り返れればと思います。セッションの前半部分は@remoreが、後半は@ganchikuが解説を担当します。 なお当日のCoplien氏によるセッション内容は、許可を得た上でYouTubeにアップロードされていますので、より深くご覧になりたい方はこちらも併せてご参照下さい。 DCI Tokyo 1 - Lean Architecture by James Coplien (Part 1 of 2)DCI Tokyo 1 -
今あえてDRY原則に向き合う
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
プロダクトに対するなぜをesaで集める - chiastolite’s blog
サービスは運用していくうちに、トレードオフをした結果だったり歴史的経緯だったり外部要因によったりで一見不思議な仕様が生まれたりする。 そういうものを途中から入った人が、頭ごなしに否定するのは幸せとはいえない。 ということでesaに↓みたいなテンプレートを作ってみた。 疑問に思ったことを書いて経緯をしってる人が答えるみたいな運用を期待している。 また回答がない記事を一覧表示できるよう、解答待ちリスト用リストを出すための記事を用意してテンプレートでそこにリンクを張るという工夫をしている。 どの機能/サービス? --- 疑問に思ったこと --- ソースコード --- (場所がわかれば。なおGitHubのリンクを貼るときは y を押してSHA1を指定してもらえると後々ズレが出なくてうれしいです) 理由 --- (可能であればコンフル/Slack/Backlogなどのパーマネントリンクも添えてくださ
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
esa.io - 趣味から育てるWebサービスの、仲間・会社・お金のつくりかた
Bootstrap Night! vol.2 でお話させていただきました https://selfree.connpass.com/event/71944/
イベント/2017/12/09/Rails Developers Meetup 2017/作らない技術 - esa-pages.io
pplog pplog stack https://stackshare.io/esa/pplog pplog iOS 先日4周年を迎えて、iOSアプリをリニューアルした pplogが4歳になった - pblog Androidは高まったらやります pplog そもそも機能を増やさない努力 居るか要らないか、世界観のために考え抜く PRして取り込んだとしてもその後revertしてゆく 「読んだよ」の連打機能 「ちょっと足跡が見えちゃう機能 」 遊び心を忘れない pplog じゃあ飽きない？ よしよし する 使う技術を変えてみたり heroku でなるべく安くがんばってみたり turbolinks でムキになったり pplog フィードバックフォームなし 言いたいことがあるときに、ポエムに含まれそうなキーワードを監視している あえての中の人感の排除 そのため@pplog_netアカウントで返
本当は恐ろしい分散システムの話
2. 2Copyright©2017 NTT corp. All Rights Reserved. 諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事 複数台のコンピュータを接続して信頼性を高めたり データが途中で化けても再送したり訂正したり 一部のコンピュータが突然故障しても引き継いだり 故障を設計の一部に組み込む事が必須となる 分散システムとは 3. 3Copyright©2017 NTT corp. All Rights Reserved. • 世はまさに分散システム戦国時代 • Hadoopを皮切りに次々出てくる巨大分散OSS • シリコンバレーでも分散ミドルウェアベンチャーが多数出現 • 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成 が前提になる • Google、Facebook、Amazon等はもちろん • 金融、流通などのエンタープラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リファクタリング 目的・パターン・思考 / reprotech
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
SOLIDの原則ってどんなふうに使うの？
レールの伸ばし方
ネットワーク ゲームにおけるTCPとUDPの使い分け
