Is age an impediment or an advantage when you are a software developer? How does experience work? What are the consequences of your decisions in your professional life? Some thoughts from a self-taught developer over 40. Read the complete speech: https://akos.ma/blog/being-a-developer-after-40/ Presentation given in Zürich, Switzerland, on April 25th 2016, at https://www.appbuilders.ch

概要 Git管理下にあるファイルをリネームした場合、 git log や git diff はそれをいい感じに処理してくれます。具体的にどういう動作をするか見てみましょう。 確認環境： /tmp/repo$ git init Initialized empty Git repository in /private/tmp/repo/.git/ /tmp/repo$ seq 100 > seq.1 /tmp/repo$ git add seq.1 /tmp/repo$ git commit -m 1 [master (root-commit) f9b660f] 1 1 file changed, 100 insertions(+) create mode 100644 seq.1 /tmp/repo$ git mv seq.1 seq.2 /tmp/repo$ git commit -m 2

「1999年か2000年頃、私は37signalsというWebデザイン企業を経営していました。2人のビジネスパートナーとWebデザインを受注していたのです」（Fried氏） Fried氏は本業とは別に再度プロジェクトとしてオンライン書籍データベースの開発に取り組んでいました。開発はPHPで行っていたものの、Fried氏はプログラミングでつまづきます。 当時はまだStackOverflowのような技術的な質問に答えてくれる掲示板などなかった時代。Fried氏はブログに「誰かこの問題を解決する方法をご存じですか？」と書き込みます。 するとデンマークからメールが届きます。メールを書いてきたのがDHH氏でした。 「私は（37signals社の）Signal vs. Noiseというブログを以前から熱心にフォローしていました」とDHH氏。 「ブログで彼の質問を見て、私は『おお、この答えを知っているぞ

──え、溝辺さんってSTORYS.JPの開発者だったんですか！ それはJPモルガンの在籍時に片手間でやられていたんですか？ 溝部氏： そうですね。 ──JPモルガンは副業とかって……。 溝部氏： もちろん駄目ですね（笑） そのSTORYS.JPは、ギリギリ黒字か赤字という収益性まで持っていけたのですが、このままではダメということで「ビットコイン面白そうじゃない？」と「Coincheck」【※】というサービスも始めました。 ※Coincheck……2012年に設立された仮想通貨の取引所サービス。複数種類の仮想通貨の売買や取引が行える。 （画像は「Coincheck」公式サイトより）──どちらも有名なWebサービスですね。それぞれ溝部さんが20代のころに立ち上げメンバーとして関わったということですか？ 溝部氏： そうなりますね。STORYS.JPは、「LinkedIn」という世界最大のビジネス

howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。

ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出て... 341 人がブックマーク・33 件のコメント

ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役

2023年10月 LayerX全社朝会資料より

Macで仕事を行っている人にとって、動作のモタつきやフリーズは絶対に避けたいもの。突然動かなくなってしまっては、仕事に支障がでてしまいます。もしかすると、そのようなトラブルは日々メンテナンスを行うことで、防げたかもしれません。 Macはすこし負荷を掛けて使っても“意外に”動いてくれるだけあって、ついメンテナンスを忘れがち。今回は、少しでも動作が重いと思ったら行っておくべき方法と、高速化アプリを30種類ご紹介します。 Macのメンテナンスと高速化のために試したい方法24選1.アプリケーションが応答しなくなったとき試すショートカットMacの動作が重いなと感じたとき、真っ先に起こりうるのが「アプリケーションが応答しない」状態。もしも、アプリケーションが固まってしまった場合、強制終了をすることで解決できます。 というコマンドを入力すると、アプリケーションの一覧が表示されます。強制終了したいアプリを

この本の概要 開発が大規模化・長期化するほど，コードを「読む」コストは増大していきます。そのため「読みやすさ」の向上は，生産性を改善し，プロダクトの成長限界を引き上げる重要な手段と言えるでしょう。 本書は，読みやすさの本質を学び，実践するための考え方をマスターできる一冊です。体系的な理解を実現するため，あらゆる角度から，豊富な例を交えて解説しています。表面的なテクニックではなく，いま目の前にあるコードに最適な改良方法を選び取る力が身に付きます。 こんな方におすすめ プログラミングの基本を学び終え，さらにステップアップしたい方 1か月以上かかる長期の開発に携わる方 コーディングのルールをどう適用するか知りたい方 はじめに 第1章　可読性の高いコードを書くために 1-1　生産性への恩恵 1-1-1　開発の規模と生産性の関係 1-1-2　可読性を高めるための環境と評価体制 1-2　可読性の高いコ

Good Code is a love letter to the next developer who will maintain it Please scroll moderately to fully experience the animations We often romanticize the notion of programming, presenting it as an abstract form of art, a science, or even a form of magic. The truth, however, is much more practical and grounded. Code, in its essence, is communication. At the start of my book, Learning JavaScript De

Red Hat Linuxの開発者であるリチャード・M・W・ジョーンズ氏が、Linux v6.4の起動時にハングアップするバグがあることに気づき、Linuxを29万2612回も再起動するテストを行ったそうです。 I booted Linux 292,612 times | Richard WM Jones https://rwmj.wordpress.com/2023/06/14/i-booted-linux-292612-times/ Dev Boots Linux 292,612 Times to Find Intel, AMD Kernel Bug | Tom's Hardware https://www.tomshardware.com/news/dev-boots-linux-292612-times-for-1-in-1000-kernel-bug ジョーンズ氏が起動時のハング

GitHubへデータサイズの大きいリポジトリをPushする際に、下記のようなエラーが発生することがあります。 remote: fatal: pack exceeds maximum allowed size fatal: The remote end hung up unexpectedly このエラーはGitHubに設定されているサイズ上限を超えた場合に発生します。 GitHubでは2GB以下のリポジトリサイズが推奨されていますが、2GB以上のサイズにできない訳ではないので、分割してサイズを小さくしてpushをしてやればエラーはなくなります。 分割pushするためには下記の手順を行ってください。 1. 分割部分のコミットにタグを作成する​ タグを作成するコミットは好きなところでいいですが、500コミットぐらいで区分してやれば問題ないと思います。 タグを作成するコマンドは下記のとおりです。

本連載は分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っていきます。第1回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 はじめまして！ はじめまして、Misskey（みすきー）のプロジェクトリーダーをしている、しゅいろ（@syuilo）です！ この度連載の機会をいただきましたので、ちょっと仰々しい気もしますが「Misskey & Webテクノロジー最前線」と題して、今後Misskeyやそれに関わる最新のWeb技術について解説をしていく予定です。 今回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 対象読者は、後半の実装解説の部分においてはある程度のWeb開発の知識がある人を想定しています。 Misskeyとは⁠、そして分散型とは Misskeyは、オープン

歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p

A global plan of action to make our online world safe and empowering for everyone The web was designed to bring people together and make knowledge freely available. It has changed the world for good and improved the lives of billions. Yet, many people are still unable to access its benefits and, for others, the Web comes with too many unacceptable costs. Everyone has a role to play in safeguarding