いやな法則
思いついたいやな法則を集めています。 生産性 何もやらないよりはだらだらやった方がまし せっぱつまらないとやらない。せっぱつまってからではできない やらなければできない。やってもできない やらなくていいことはできる やらなければいけないことは楽しくない やらなくていいことをやっている人はいきいきしている 横着をするための労力を惜しんではいけない 横着をするための労力を惜しんではいけない、という口実で現実逃避してしまう 現実逃避の方が生産性が高い いやな仕事は、もっといやな仕事があるとき、いやではなくなる 決断 正しいことはすぐに中断し、間違ったことには頑固にしがみつく どちらかじゃなくて両方欲しい アイディア 考えて出てくるアイディアにろくなものはない アイディアを探してもアイディアは出てこない すぐにでも実行したいアイディアは嫌な仕事をしているときに思いつく よいと説明しないとわからない
Infrastructure-as-Code-is-very-tired
ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
ぼくはこうしてプログラミングを覚えた
オリジナルはココです。フェイスブックのエンジニアで史上ベスト３に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。 手短かに言えば 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、（フェイスブックで働いていた）過去４年間、ほとんど他のことをしていない。その前も２.５年ほどプログラマーとして働いていたし、そのさらに前も６年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで（最初はMac Plusで途中からIIsiになった）で散々遊んだ。８歳か９歳の
オーバーエンジニアリングの正体とその向き合い方 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 問題は細部（あるいはその欠如）にあり。 議論とは、ソフトウェア開発の基本的な構成要素であり、スケーラビリティを向上させるためには避けられない摩擦であると言えます。議論を通して私たちは出来上がるものの品質に影響を与え得るような問題を早い段階で浮かび上がらせることができるのです。その1つがオーバーエンジニアリングの問題です。 ウィキペディアによると、オーバーエンジニアリングとは下記のとおりです。 十分な 安全率 や十分な機能の確保のためか、あるいはデザイン上の誤りのどちらかの理由から、アプリケーションが必要とする以上に強固で複雑なプロダクトがデザインされてしまうこと。 また、ウィキペディアには、オーバーエンジニアリングが好ましい場合として、さらに、このようなことも書いてあります。 ある特定の基準の下で安全
次のfacebookを目指してなんの意味がある？ Ruby on Rails 作者が語る「お金を生み出して幸せになるためのたった１つの方法」
Ruby on Rails（オープンソースのフレームワーク）の作者であり、37Signals（米のウェブアプリ開発会社）のパートナーでもあるDavid Heinemeier Hansson (デビッド ヘイメール ハンソン、通称DHH) が2008年にStartup Schoolで語ったスピーチを翻訳＆書き起こし。 Ycombinator（米のベンチャーキャピタル）が主催するこのスタートアップスクールで、「ベンチャー・キャピタルからお金をもらって次のFacebookを狙うのをやめよう！」とアンチ・スタートアップ、アンチ・ベンチャーキャピタルを主張し、人が本当に幸せになれる生き方について説いた、非常に興味深いプレゼンです。 ※この記事は「TURN YOUR IDEAS INTO REALITY.」からの寄稿です。見出し等一部編集してあります。 なお、この翻訳を書くにあたって筆者がDHH氏にツ
「巨大プルリク1件vs細かいプルリク100件」問題を考える（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 100 Duck-Sized Pull Requests 原文公開日: 2017/12 著者: Kurtis Funai 日本語タイトルは内容に即したものにしました。 2018/02/07: 初版公開 2022/02/24: 更新 Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 本記事では、昔ながらの問題である「巨大なプルリク1件と超細かいプルリク100件、どっちなら戦う気になれる？」に対する回答を示したいと思います。チームの一員としてよりよいコードを書くためのガイドラインについてもある程度解説します。今回の記事は、すべて以下のツイートから触発されました。 10 lines of code
エンジニアが重要なことにフォーカスできなくなるいくつかのパターン｜yuta ishizaka
プロダクトを向上させて事業を成長させるために、"重要なことにフォーカスすること"は最も大事な事項のひとつだ、ということはみんなわかっていると思う。 にも関わらず、実際にはフォーカスを失ってしまうことがよくある。いくつかのパターンと解決策を書いてみたい。 1.隣人駆動開発(Neighbor Driven Development)パターン エンジニアは、時として"身近な人に感謝される仕事"を優先してしまう。 例えば、サポートチームから「管理画面のこの機能がちょっと使いづらいので変えてくれないか」と言われる。 すぐに対応してリリースすると「ありがとう！頼りになります！」と言われる。当然、いい気持ちになる。 その後、ユーザー体験をよくするための重要な開発をやっている時に、またサポートチームから「ここをちょっと変えてほしい」と言われる。 今度は、今ちょっと手が空かないから待ってくれと言う。 そして、
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
カーゴ・カルト・プログラミング - Wikipedia
カーゴ・カルト・プログラミング（英: Cargo cult programming）とは、コンピュータープログラミングにおいて、実際の目的には必要のないコードやプログラム構造が儀式的に含められているという状態で特徴づけられる悪習である。カーゴ・カルト・プログラミングは、プログラマが、自身が解決しようとしている課題やバグ、明らかな解決策を理解していないことを示す兆候である（ショットガン・デバッギング（英語版）やブードゥー・プログラミング（英語版）も参照）[1]。 概要[編集] カーゴ・カルト・プログラミングは、目の前の問題について経験の浅いプログラマが、他の場所にあるプログラムコードを、その仕組みや、それが本当に必要かどうかを理解することなしに、別の場所にコピーするときに生じうる。 また、他の場所で見つけてきた設計手法やコーディングスタイルを、それが生まれた背景理由などを理解しないまま盲目的
優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～/Concise Guide to Finding the Best Technical Talent
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～」講演資料です。
Big Sky :: Rob Pike のプログラミングに関する5つの掟
« git で pull-request を clone する設定が覚えられないので alias 書いた。 | Main | Vim で peco する「veco」書いた。 » 掟1 プログラムが時間を費やす箇所がどこにあるのかは知り得ない。ボトルネックは意外な場所で発生するため後知恵で批判してはならないし、ボトルネックがどこにあるか証明出来るまではスピードハックを入れてはいけない。 掟2 測定しよう。測定し終えるまでは、さらにはコードの一部分が残りのコードの支配的な量とならないならばチューニングを行ってはいけない。 掟3 凝ったアルゴリズムは、n が小さいときに低速となり、通常 n は小さい。凝ったアルゴリズムは大きな定数を有する。n は頻繁に大きくなり得ることを知るまでは凝ったアルゴリズムを得てはならない。 (n が大きくなる場合であっても、まず掟 2 を行いなさい） 掟4 凝ったアル
「好きな技術」がある時/ない時 - 圧倒亭グランパのブログ
「好きな技術はなんですか？」 こう聞かれた時、今の自分は真っ先に「crystal言語」と答えます。ですが、昔の自分は好きな技術を明確には持っていませんでした。この 好きな技術がある時/ない時 を振り返ってみると、いろいろと違うなと感じたのでまとめます。 目次 目次 好きな技術がない時 好きな技術がある時 嬉しい二つの効果 周辺知識が自然とついてくる 自分に「特定のイメージ」がつく 好きな技術を持つには まとめ 好きな技術がない時 好きな技術がない時を振り返ってみると、総じて 受け身 でした。 「好きな技術は？」と聞かれても答えられない ウォッチしている技術もなく、躓いた時に調べる程度 「みんなやってるから」という理由で勉強会に参加 周りと比べて自分だけ知らない技術は慌てて調べる 「この本良いよ」という本は買うが、積ん読が増えていく 自発的な行動ではなく、周りが発端となって行動しています。こ
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog;
僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる
人付き合いの話 - kawaguti’s diary
周りの目が必要以上に気になってしまう人がいます。たぶん生まれ持ってしまったか、家庭や社会の環境との付き合いで長い時間をかけて作られてきたそうした感覚なのだろうと思います。もし生存のために必要に迫られて獲得した能力だとすれば、急に変えるなんて難しいでしょうね。 私ももちろん相手が自分をどう思っているかは大変気になります。ものを教えたり、アドバイスするようなことを仕事にしてしまっているこの数年は特にそこは重要になりました。しかし相手の心なんてどうあってもコントロールできない。ストレスがある環境下でパフォーマンス出せるほど、人間がうまくできてないし...。どうするか....。 で、私なりにいくつか心がけていることを書いてみます。 なるべく攻撃してくる人や話が合わない人とは付き合わず、認めてくれる人とだけ付き合うようにしていけるといいなぁと思います。生きて行くために何人と付き合わなければならないか
暴言は敗北を招く、その科学的な裏付け
[ボードに投稿する際の諸注意](http://boards.jp.leagueoflegends.com/ja-jp/c/game-discussion/u4dTQsPt-iiisoozso) *** **リーグ・オブ・レジェンド** [ゲーム全般](http://boards.jp.leagueoflegends.com/ja-jp/c/game-discussion) [ゲームプレイ&戦術](http://boards.jp.leagueoflegends.com/ja-jp/c/gameplayandstrategy) [コミュニティー・イベント](http://boards.jp.leagueoflegends.com/ja-jp/c/community-event) [初心者向け](http://boards.jp.leagueoflegends.com/ja-jp/c/begi
関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘
関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘 一般にプログラムは多くの関数などから構成されています。関数には数百行に渡る長いものから数行程度の短いものまでさまざまな長さがありますが、果たして関数にとって適切な長さというのはあるのでしょうか？ マーチン・ファウラー氏は関数の長さについて書いたコラムで、重要なのは意図と実装の分離であり、適切な名前を付けることが大事だと指摘します。同氏のブログは翻訳が許可されているので、記事「FunctionLength」の本文を翻訳しました。 FunctionLength（関数の長さ） 私のキャリアにおいて、関数の長さはどれくらいであるべきか、という議論を何度も聞いてきた。これはより重要な問いに置き換えることができる。それは、どのくらいの長さのコードになったらそれを関数にすべきか、ということだ。 い
コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと - きょくちょ日記 -THERE'S ONLY MAKE!-
これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした！ それは、今からちょうど半年前のこと。 海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。 開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう！」と提案があり、それから本格的にコードレビューをやり始めることになりました。 早いもので、あれから半年が過ぎました。 今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。 教育関連に興味がある方や組織の成長を考え
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
社内技術勉強会で「技術ブログを書くことについて」発表しました - Hatena Developer Blog
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてなで毎週開催している社内技術勉強会で発表した「技術ブログを書くことについて」という発表資料を公開します。 speakerdeck.com 今回の発表をなぜ行ったかというと、もっと気軽に自分のやったことをブログに書くといいのではという考え方を社内に伝えたかったからです。エンジニアをしていると、ブログを書くときは他の人が書いていないことしか書いてはいけない、しかも完璧に書かなければならない、というような気持ちになることもあります。しかし、ブログを書くことで自分の学習をより深め、加速することもできるので、あまり気負いせずにブログを継続して書いて欲しいという思いを発表しました。これがエンジニアのブログに関する正しい考え方と言い張るつもりはなくて、一つのブログに対する考え方として、参考になれば良いなと思います。 発表で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
