コードの写経中にやってること - 覚書
ソフトウェアのプログラミングの文脈でソースコードの写経と呼ばれるものがあります。簡単に言うとソースコードの読み書き技術の上達のために既存のソースコードを手元で入力する作業です。最近ではgithubなどでOSSが大量に公開されているのでいくらでもできます。 写経は明確に定義がある言葉ではないので、ただ無心に写すという人もいるでしょうし、写しながらその他のことをする人もいるでしょう。ここでは私が「(ソースコードの)写経をする」といったときに何をしているのかを、だれかの参考になるかもしれないので書いておきます。なお、別にこれが唯一絶対とかいうつもりは毛頭ないです。 (とくに不慣れな分野、言語において)何をしたいときにどういうライブラリを使うか、どういうコードを書くかというパターンを覚える、およびそれを体に叩き込む コードを書いたときの作者のお気持ちを推測する 実際に書かれているコードと自分ならこ
SmartHR CTOが語る中長期戦略。徹底的なアプリ開発とAPI対応で「プラットフォーム化」促進へ - SmartHR ガイド
2019年1月11日に、株式会社SmartHR 2019年全社キックオフを開催しました。 同キックオフにて、SmartHR CTOの芹澤 雅人が「プロダクト開発方針 〜中長期戦略編〜」と題し、発表しました。 その内容を全文書き起こしにてお届けします。 （以下本編） SmartHR一本で「T2D3」を達成できるか？ 先ほど副島さんから、これまでのSmartHRの変遷についてお話がありましたが、僕からは、今後SmartHRを中長期的にどう開発していくかのお話ができればと思います。 突然ですが、問題です。 「SmartHR」というプロダクト一本で、「T2D3」（*）を達成できるでしょうか？ *T2D3：ARR（サブスクリプションの年間売上）が1億円を突破してから、3倍（Triple）×2年、2倍（Double）×3年で売上が伸長するのが理想という、SaaS業界理想の成長スピード 答えは……、 で
ポーギーに話す
John Graham-Cumming / 青木靖 訳 2010年5月17日 プログラマであれば、何かの問題を同僚に説明していて、説明し終わる前や、何かフィードバックをもらえる前に自分で答えを見つけたという経験があるのではないかと思う。私は同僚さえ必要ないということに気づいた。話す相手は何でも良くて、ただ問題を口に出しさえすればよいのだ。 私が本を書いていたとき、解説しようとしている科学の話を自分でちゃんと理解しているか確認するため、声に出して説明してみることが良くあった。あまりばからしく感じないように猫を相手にそうしていた。猫は私の言うことを理解しないか、少なくとも言葉を返すことはなかったが、はっきり口に出して言うのはとても助けになった。 デバッグしているときコンピュータに話しかけることもある。問題をはっきり口に出すことで頭の中の歯車がかみ合って、自ずと答えが出てくるのだ。 Coders
プロジェクトの成功を支える ZenHub と モブプログラミング / ZenHub and Mob Programming
プロジェクトの成功を支える ZenHub と モブプログラミング / ZenHub and Mob Programming
説得する必要のない人を説得しない - 西尾泰和のScrapbox
他人が自分と異なる意見を持っている場合に、人はしばしばそれを説得しなきゃいけないような気になってしまう。
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
1000人体制でもエンジニアが成長する組織とは？ 海外事例から学ぶテックキャリアの拡げ方【メルカリ CTO・名村卓】 - エンジニアtype | 転職type
この連載では、注目企業のCTOが考える「この先、エンジニアに求められるもの」を紹介。エンジニアが未来を生き抜くヒントをお届けします！ 先々のキャリアを見据えたとき、どんな仕事をするか、と同じくらい重要なのが「どんな組織で働くか」だろう。では、エンジニアが伸びる組織とは、一体どんな組織なのだろうか？ 第二回の「CTO’s CAREER STRATEGY」では、急速に人が増え、成長を続ける株式会社メルカリのCTOである名村卓氏に、そんなエンジニアたちの疑問をぶつけてみた。 人が増えれば組織の都合が優先され、一人一人の成長をきめ細やかに支援することはおろそかになりがちな印象だが、ことメルカリに関しては、どうも様子が違うように感じる。それもそのはず。メルカリはグローバルテックカンパニーを目指すことを表明し、10月にはAI/MLの活用、マイクロサービス化への取り組み等最新技術領域について発表するイベ
CASHのユーザビリティを支える（泥臭い）技術
クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achieving BizDevOps in in-house development of cloud-native energy-saving services
「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018 | CyberAgent Developers Blog
（2019/04 追記 現在メディア管轄のAWSアカウントでは、IAMユーザーの管理に、Permissions Boundaries を活用しています。） メディア事業で、AWSやGCPといったパブリッククラウド関連の業務を担当しているインフラエンジニアの柿島大貴です。前回、ホンネテレビの負荷対策プロマネのホンネ を書いてから半年ぶりの投稿となります。 本日、チームメンバーの東とAWS Summit Tokyo 2018で、「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み というタイトルで発表をさせていただきました。発表資料は以下となります。 今回、2016年にアドベントカレンダーの記事として公開した以下の記事がきっかけで登壇のお話をいただきました。 「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み 発表の中でも紹介していますが、このブログの公開後、一度この
iOSとAndroidの段階的リリース機能を比較する - 一休.com Developers Blog
この記事は一休.comアドベントカレンダー2017の25日目です。 一休レストランiOSアプリを開発しているid:ninjinkunです。 iOSでは今年の夏からiTunesConnectにて段階的リリース（Phased Releases）が導入されています。段階的リリースとは、アプリの新バージョンを提供する際に一部のユーザーから順にアップデートを適用していくリリース方法です。不具合があった際に全ユーザーに影響が及ぶことを防ぐことができ、リスクを低減することができます。 この機能にの詳細については、 iOSの段階的リリースについての注意点 - inFablic | Fablic, inc. Developer's Blog. が詳しく、本エントリは追試 + 以前に使用した経験があるAndroidの段階的リリース（Staged Rollout）との比較になります。 結論を先に書くと、この機能
プログラミングにおける認知バイアス - Frasco
開発者として、私たちは生産性を妨げる様々な問題をよく知っています。しかし、広い視野で物事を見ることに関して見過ごしがちです。 認知バイアスにより、生産性の低下、バグ、フラストレーションを招く可能性があります。これらの影響を最小限に抑えることができれば理想的です。本記事では、プログラミングする際に知っておくべき5つの認知バイアスを示します。 双曲割引（Hyperbolic Discounting） 後の利益よりも直近の利益を優先する あなたはテストを書くのを遅らせたことがありますか？Vim を使う際、矢印キーを使ってカーソルを移動させたことがありますか？おめでとうございます、それが双曲割引です。HJKL による慣れない操作を覚えるよりも、矢印キーを使用するほうが楽でいいでしょう。しかし、一度 HJKL による移動方法を学ぶと、将来の利益は遥かに高くなります。結果として、あなたは多くの時間を節
One for all, all for one- The Journey to Android Monorepo at Uber
Managing code across multiple repositories at scale impedes developer productivity, comes with a cost of duplication of tooling, processes and dealing with breaking api changes in non atomic change-sets. At Uber, the Android codebase moved from 100+ repositories into a single monolithic repository. This massive migration was done while ensuring VCS history is preserved, breaking API changes across
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新規チームで新規開発を始める時にやること
技術的負債を "なるべく" 作らないためのコツ / Organization Performance Tips
SimpleとEasyは違う / Simple is not Easy
プロジェクトをリードする技術 (Kyash 社 再演) / Project Leading is Skill for Kyash
まつもとりースタイル
レビュー評価4.7の秘密 / The Secret To A Better Reputation
