Flutterアプリにおける、過不足ない設計の考察🎅
Photo by Hush Naidoo Jade Photography on Unsplash「一般的なモバイルアプリ」の設計全般において、特に何に気を付ける必要があるか、あるいは逆にあまり気にしてなくても良いのではと思うことなどを述べていきます。 (…のつもりでしたが、後者含めると1記事に収めるの困難で、最後にさらっと触れつつ別記事で手厚く書きたいところです🤔) ここでの「一般的なモバイルアプリ」は規模観点では以下程度のイメージですが、それを超えるような規模でも通ずる内容も多いと思っています。 コード量: 数万〜十数万行実装者: 一桁人種類としては(スマホ向けの)クライアントアプリコードであり、以下などではないです。 パッケージ・ライブラリではないサーバーサイドではないこの種類によって適切な組み方はけっこう変わり、アプリコードは依存関係の末端側(基本的に依存される側にはならない)な
Kubernetesでステートフルなゲームサーバを動かした思い出
とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で
GoのAPIのテストにおける共通処理
GoのAPIを書くとき、参考になるユニットテストの話は非常によく見ます。Table Driven Testをしましょうとか、サブテストの実行とか、そのあたりの話はたくさん書かれています。 また、テストキャッシュなども出てきましたので、ユニットテスト周りの機能・ノウハウは充実していると感じてます。 一方で、httptestを使ってテストサーバーを立て、リクエスト/レスポンスの内容を検証する場合、単一のリクエストを検証する程度のサンプルにとどまっていたり、あまり共通でこういう処理を書いてるよ、みたいなノウハウがなく、自前で一から書くとなると非常に腰が重くなります。 事実自分はそういう経験をしました。そういった共通処理は普段internalパッケージの中の、testutilsとしてまとめる、などしています。 今回はGoで上記のようなテストを書く場合、どういう共通処理が必要となったかをテーマとして
12 Factor CLI Apps – Jeff Dickey – Medium
CLIs are a fantastic way to build products. Unlike web applications, they take a small fraction of the time to build and are much more powerful. With the web, you can do whatever the developer programmed. With CLIs, you can easily mash-up multiple tools together yourself to perform advanced tasks. They require more technical expertise to use, but still work well for admin tasks, power-user tasks,
PMFを狙うスタートアップの開発戦略 – SOELU Developers – Medium
最短でサービスをローンチするサービスが世に出ない限り、検証は何も始まりません。最短でサービスをローンチするための技術選定を行う必要があります。 技術的な冒険はしない重要なのは『チームをリードできる技術を使うこと』であると考えています。最も自分が精通している技術で、メンバーが躓くことなく一直線に開発できるようサポートする必要があります。私の場合、最も手に馴染んだ言語がRubyであったため、Rubyを選択しました。 コードを書かないことに勝る手段はないまた、『いかにしてコードを書かずに済ますか』という観点も重要です。成熟したフルスタックフレームワークを使用することで、自分たちで書くコード量は圧倒的に短縮できます。私たちの場合、Ruby on Railsを使うことで多くの処理をGemに丸投げし、管理画面はRailsAdminを使用することで開発時間を圧縮しました。Railsはもちろん銀の弾丸では
メルカリの小泉さんと組織の課題について話したら恐ろしい程勉強になった話 – tsukuruba – Medium
僕の中で仕事人生に影響を与え続けてくれている三大COO（と勝手に呼んでる人たち）がいる。 一人目がアカツキ共同創業者COOの香田哲朗くん、二人目がフリークアウト(元)COOで現hey代表の佐藤裕介さん、そしてメルカリ社長兼COOの小泉文明さんだ。 それぞれ社長もできる人だが、COOとして事業及び組織の構築も構造的分析もハイレベルにできる。恐ろしく広域のアビリティを持ち、バイタリティとバランス感覚に優れ、超人的な仕事量をこなす人たちである。 そのうちのお一人であるメルカリ小泉さんと1on1させてもらう機会があり、その話が組織の課題に悩む他の人にもとても有用だと思ったのでメモを公開させていただくことにした。（ほんとにメモなんで乱文ご容赦ください） ツクルバでは組織・文化づくりに社をあげて徹底的に投資していく方針なので、非常に参考になった。 ＊＊＊以下メモ＊＊＊ [お題] メルカリで急激に組織を
NewsPicks におけるサーバーサイド Kotlin 活用事例
はじめにこの記事では NewsPicks での Kotlin 活用事例 — — ただしサーバーサイドでの活用事例 — — について紹介します。今秋 9 月から 10 月にかけて、NewsPicks で新しいスマホアプリを開発する機会があり、その際のサーバーサイド開発に Kotlin を利用しました。開発チームの発足が 9 月、仕様設計から開発・リリースまで約 2 ヶ月と比較的短い時間軸での開発だったのでそれほど規模が大きいものではありませんが、サーバーサイドに関してはほぼ僕が一人で開発したこともあり、知見の共有も兼ねて筆をとった次第です。 サーバーサイド Kotlin は少しずつ流行りつつあると思うのですが、まだまだ世間には事例が少なく、採用を躊躇している方も多いのではないかと思います。長文にはなりますが、この記事が何らか皆様の参考になれば幸いです。 対象読者この記事では主に「サーバーサイ
シリコンバレーと天下の回りもの
Yearly Federal Tax Calculator 2018/19: 2017 tax refund calculator with Federal tax, medicare and social security tax… ということで、老後に向けて毎月1,500ドル(401K Deduction、毎月16万5千円)も積立てしているにも関わらず、手取りが毎月14,477ドルです。159万2千円ですね。ちなみに年金もちゃんと払っているので、フラグさえ立てれば、だいぶ少ないながらも返ってきます。 現金だけじゃなくてRSUがあるでしょ? という疑問が出ます。が、vestingと同時に売却すれば、そのまま現金になります。マーケットの急激な上昇または乱高下は、そう滅多にあるものではありませんから。 独身者がシリコンバレーで暮らすにあたって、最低限の生活費は、とりあえず、こんな感じでどうし
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
ソフトウェアエンジニアのUSビザ
「アメリカ就職に失敗したはなし」で盛り上がっているアメリカ就労ビザ話。学歴がないとダメとか、修士以上がイイとか、いろんな意見が出てますが、ここらではっきりさせときます。 Demystifying U.S. Visa! H-1Bまずは、アメリカ就労ビザの花形「H-1Bビザ」。 ざっくり言うと以下のとおり。 企業にスポンサーになってもらう必要がある条件がある毎年4月から申請開始、10月から働ける申請者が多すぎるので抽選になる転職できるH-1Bの条件ソフトウェアエンジニアとしてH-1Bを申請してもらいましょう。条件を満たしているかどうか、次のフローチャートで確認できます。 見てのとおり、学歴は必須条件ではありません。 実際には、移民弁護士と膝を突き合わせて、成績表を眺めながら、コンピュータ・サイエンスの単位として使えるものをピックアップしていく作業が必要ですが、大雑把な傾向としては次のとおり。
REST is the new SOAP
Written by Pascal Chambon, reviewed by Raphaël Gomès Update: this article mostly deals with the RESTish ecosystem, which now constitutes a major part of webservices. For more in-depth analysis of the original REST, and of HATEOAS, see my follow-up article. How come REST means so much WORK? This is both a paradox, and a shameless pun. Let’s dive further into the artificial problems born from this d
エンジニアが「明日からマネジメントして」と言われたら
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
休日にカンファレンスがあるときに、参加者はどうするか？
土日や祝日にフルタイムで技術カンファレンスがあるとして、例えば参加しますよね、そのときにどうするか考えようという提起です。 カンファレンスは疲れるセッションを黙って座って聴いてるだけでもそれなりに疲れるし、せっかく参加するなら登壇者の人を捕まえて話をしたり、他の参加者と議論したり、もしくはワークショップセッションに参加したりとかしますよね。聴いてるだけみたいな参加の仕方をしても「あとで資料だけみればいいや」程度の価値しかないから。なので、フルタイムで1日参加するとそれなりに疲労するわけです。楽しさとは別に。 土日2daysなカンファレンスの場合、前の週フルタイムで働き、土日に疲労し、次の週またフルタイムで働くとか、たぶん働きすぎなので、最低でも次の月曜とかは休みたくなるのが人間ってものだと思います。私はそうする。 平日カンファレンスの参加は休暇を使いますか？CROSS 2016に登壇したと
フロントエンド開発の概要について
ここでは、フロントエンド開発の概要について説明していきます。 ＊元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
タテマエメソッド
POV madlib by d.schoolPOVはpoint of viewで「視点」という意味、madlibは「穴埋め問題」のことを指します。つまり、穴埋め問題を記入することによって、視点をうまく切り替えながら、課題を解決していきましょう、というものです。 オリジナルのテンプレートは以下のとおりです： [USER] needs to [USER’S NEED] because [SURPRISING INSIGHT] | ［ユーザー］は［ニーズ］をする必要がある。 | なぜなら［驚くべきインサイト］があるからだ。 「東京工業大学エンジニアリングデザインプロジェクト」でも当初はこのテンプレートを使っていましたが、どうもありきたりというか、当たり前の視点しか出てきませんでした。よくあるのは「友達に伝えたいからだ」のような社会的な欲求、「役に立つからだ」のような機能的な欲求、「楽しいからだ」
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
アジャイル界隈研修の感想まとめ
自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと
ベトナムでWeb開発する時に知っておきたい20のポイント
初の訪問で発見した事をつづります 石井＠ハノイ長期出張中です。 元はと言えばシリコンバレー滞在中に、 ベンチャーバブルによるプログラマー人件費高騰を目の当たりにし、 例えばRuby on Rails開発者の年収平均が1000万円というサンフランシスコでは、 とてもプログラマーを雇えないなと感じた事から、 ITに強く人件費の安いベトナムは気になっていました。 弊社内にCTOは必要ですが、 CTOの部下となる開発チームは中長期的に日本の地方もしくはアジアの人件費の安い都市に構えないと、 会社の固定費がかかりすぎます。 今回はベトナム・ハノイに2週間滞在し、 様々な発見がありましたのでリスト化したいと思います。 海外の人件費の安い地域にWeb開発を外注する事をオフショアといいますが、 今回の出張中に回らせていただいたオフショア開発会社さんは下記の通りです。 エボラブルアジア フランジア リケイソ
シリコンバレーで僕らが500 Startupsに投資されるまで
この記事は、スタートアップについて何も知らなかった僕が、1冊の本との出会いによって、シリコンバレーに“招待”されるまでの経験を綴ったものだ。《カスタマーデベロップメント》という手法に出遇うことで、単純に顧客の課題や製品について検証をするのみならず、思いがけない素晴らしいご縁やセレンディピティにも恵まれて、シリコンバレーで仕事を始めるためのスタートラインまで導いてもらえた経験について記している。 転身（けれど、何も分からず、アイディアや事例先行で失敗を繰り返す）検証の旅（アドバイザーの一言。長旅の暇つぶし。検証開始。ビルの外に問題と顧客候補があった）セレンディピティと奇跡（思いがけない出遇い、招待、投資） 転身2009年7月、右も左もわかないまま、僕はスタートアップの世界に飛び込んだ。完全にゼロからのスタートだった。コンピュータサイエンスのフィールドにてPhDを取得した直後、僕は大学院での研
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tough love between mysql2 Ruby gem and MacOS Mojave