技術的負債とどう向き合っているか？ ITベンチャー4社が語る、開発チームのリアルな裏側 Part3
技術的負債とどう向き合う？ 広木：では次のテーマにいきましょう。弊社の技術的負債について。デプロイパイプラインの自慢をさせてくださいってやつですね。どうでしょう？ 横路：マイクロサービスって「最初からマイクロサービスにするな」って言われるでしょ？ うちには育ち切ったモノリスがあります！ 広木：すばらしい！ 横路：ぜんぜん自慢できることじゃないんですけど。サービスが8個くらいあるんですが、最初の会計サービスは丸々と太っていて、もうフォアグラですね。だいたいRailsなんですが、クックパッドのコアの部分も相当じゃないですか。あれの半分くらいはあると思います。 なので、モデルもコントローラーの数もだいたい数千ですね。フロントエンドのコードも数十万から100万行くらいですね。それをこれからしっかりマイクロサービス化していけるのがうちの強みだと思ってます。 マイクロサービスが役立つのはだいたいあれで
デスクトップにダークモードが登場。使用方法をチェックしよう！
デスクトップにダークモードが登場。使用方法をチェックしよう！Slack ですべてのデスクトップアプリ、Mac、Windows、Linux でダークモードが利用可能に Slack チーム一同作成2019年9月12日イラスト: Josh Cochran 夜間や暗めの環境で仕事をしたい？アクセシビリティ目的（視覚障害、片頭痛、その他の視覚障害など）でダークモードを利用したい？または、ただ単にダークモードが好きなだけ？その理由が何であれ、ダークモードをご希望の皆様に朗報です。ついに Slack でダークモードが利用可能になりました！ わかりやすく、疑問点にいくつか答えられるよう、いくつかのセクションに分けてこの機能を説明します。 どんな機能？すべてのプラットフォームのアプリでダークモードを使用できるようになりました。 利用できる場所は？もちろん、Slack です。具体的には、本日のリリースはすべて
useEffect完全ガイド
あなたは Hooks を使って複数のコンポーネントを書きました。ちょっとしたアプリも作ったことがあるでしょう。満足もしている。API にも慣れて、その過程でコツも掴んできました。しかも重複したロジックを転用できるよう Custom Hooks を作り、同僚に自慢して見たり。 でも useEffect を使う度、いまいちピンときません。class のライフサイクルとは似ているけど、何かが違う。そしていろんな疑問を抱き始めます。 🤔 componentDidMount を useEffect で再現する方法は？ 🤔 useEffect 内で正確に非同期処理を行う方法とは？ []ってなに？ 🤔 関数をエフェクトの依存関係として記すべき？ 🤔 非同期処理の無限ループがたまに起こるのはなぜ？ 🤔 古い state か props がエフェクト内にたまに入るのはなぜ？ 私も Hooks を使
昨今のJavaScriptをレビューしたら全くわからなかった話 - aoma blog
はじめに 最近JavaScriptのプルリクが来たので「よーしやったるでー」って感じでレビューしたんですが、まったく理解できずレビューになりませんでした。 その時疑問に思ったことをメモします。。 誰かの助けになれば幸いです。。 これはもう引退やな。。 classの中で function って書くの省略してるの？ class TestClass { test() { 処理 } } function を省略して書けるのかなと思ったらそうではない。むしろ書いてはいけない。 下記はエラーになる。 class TestClass { function test() { 処理 } } PHPに慣れてるからか、もやもやする。 (a, b) => は無名関数なのはわかったけど function(a, b) じゃダメなの？ (a, b) => は無名関数で function(a, b) と同じ。 好みの問題
【書評】「レガシーコードからの脱却」の9つのプラクティスは圧倒的に正しい（経験者談） - give IT a try
はじめに 株式会社アトラクタの原田騎郎さん（@haradakiro）から、書籍「レガシーコードからの脱却」をご恵贈いただきました。（どうもありがとうございます！） せっかくいただいた本なので、本書を読んだ僕の感想を書いてみようと思います。 どんな本なの？ 端的に言うと、「初めからレガシーコードを作りださないための9つのプラクティスを説明した本」となります。 最初にタイトルを見たときの印象は「今そこにあるレガシーコードを、どうやってイケてるコードに書き直していくのか？」を説明した本なのかなと思ったんですが、本書が主眼としているのは「そもそもレガシーコードを作らないこと」でした。 ですので、「レガシーコード改善ガイド」とは毛色が違う本だと考えた方が良さそうです。 （「レガシーコード改善ガイド」は、「今そこにあるレガシーコードを改善する方法」を解説した本です） レガシーコード改善ガイド (Obj
"技術顧問" のお仕事｜Sotaro Karasawa
"技術顧問" 👨🏻💻ブームだな〜と思ってて、ソフトウェアエンジニアや一定の経験を積んだ人たちが、他のそういう知識・経験の無い会社を副業や業務委託という形でサポートしていくのは良いしどんどん広まると良いな、というのがある一方で、"技術顧問" という言葉が独り歩きしていて、 ・それってどういうことをやるひとなの？ ・(エンジニアにとって)自分が技術顧問になってほしいと言われたらなにをやるの？ ・(技術顧問が必要かも? という経営者にとって) 自分たちに必要なのはどういう人達なのか などがあまりハッキリしないままで、今現在、仕事の内容も単価もおぼつかない状態で混沌💥としていると思います。 など、かつてのCTOブーム、VPoEブーム、エンジニアリングマネージャーブーム等同様(まぁ、ブームっていうのは若干自虐的揶揄も含みつつではあるものの) 言葉が独り歩きして爆発的にそれっぽい人が増える、
どういう時に仕事を辞めたくなるか - Konifar's ZATSU
まだ現職辞めへんで！！ということを最初に宣言しておきつつ、どういう時に仕事/会社を辞めたくなるかを考えてみたい。 朝眠いとかだるいとかそもそも働きたくないとか5000兆円欲しいとかそういうやつではなく、基本的にはやる気がある状況でもふと環境をリセットしたくなるというか、ああなんだかめんどくさいなーと感じるみたいな、比較的ライトな感情の変化の話である。人によっては「にゃーん」とツイートしたり、シャワーを浴びながら「つらい…」とつぶやいてしまったりするアレだ。 なんでこんなことを考えてるかというと、最近TL上で「この人が辞めるのマジか」とか「この人が入社したのかすげえ」と感じることが何度かあり、全然そんな素振りを感じなかったのにやはり一期一会なのだろうかと思ったことがきっかけである。仕事を辞めるのにポジティブな理由だけということはまずないという持論がある。 自分にも感情の波みたいなものがあって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
