Weird Lexical Syntax
I just learned 42 programming languages this month to build a new syntax highlighter for llamafile. I feel like I'm up to my eyeballs in programming languages right now. Now that it's halloween, I thought I'd share some of the spookiest most surprising syntax I've seen. The languages I decided to support are Ada, Assembly, BASIC, C, C#, C++, COBOL, CSS, D, FORTH, FORTRAN, Go, Haskell, HTML, Java,
個人開発者が参考にすべき人・読んでおくべき記事一覧まとめ
こんにちは、ネットではウマたんというハンドルネームで活動していて普段はAIデータサイエンスに関するスタビジというメディアやスタアカという教育サービスやYomeruという書籍レビューサービスを運営しています。 元々の専門はAIデータサイエンスなのですが、数年前からちょくちょく個人開発をやるようになり色んな記事を参考にさせてもらっています。 せっかくなので、僕自身が何度も読み返したい記事をこちらに備忘録がてらまとめていきます。 日本人編 Takuya Matsuyamaさん 海外向けにInkdropというエディタを開発してめちゃくちゃ稼いでる。Youtubeもすごい 参考になる記事 個人開発をする上でまず最初に読んでおきたい記事。「最初はとにかく最速でリリースする事を最優先する」「迷ったら「ときめく方」を選べ」 プライシングの話からYoutubeを使ったブランディングの話まで、個人開発者が集客
個人開発マネタイズ大全
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
詰め込み型のソフトウェアプロダクト開発は誰も得しない｜mtx2s
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
DevOps への投資に対するリターンを計算する方法
DevOps や Platform Engineering, Developer Productivity など、開発活動の生産性を高める活動や分野を指す言葉が広く謳われるようになってきましたが、その活動を始めようと思っても効果について説明するのは難しいなと感じていました。 そんななか、Google Cloud による The ROI of DevOps Transformation という、DevOps 施策の ROI を計算する方法がいくつか紹介されている記事を見つけました。 この記事の内容がそのまま使えるかと言うと判断に困るのですが、面白かったので 1 つの計算方法として紹介していきたいと思います。 前提 Four Keys について DORA の研究によって、Four Keys 指標は組織のパフォーマンス（収益性、品質、顧客数、満足度など）に相関関係があることが分かっています。 F
不要な処理が実行速度を速くする謎を追う - Money Forward Developers Blog
こんにちは。 id:Pocke です。マネーフォワードでは Rails を用いた Web アプリケーションの開発と、RBS という Ruby の静的型システムの開発を行っています。 最近 RBS の開発をする中で、「不要な処理を削除すると実行速度が遅くなる」という不思議な現象に遭遇しました。この記事ではその現象を解説しようと思います。 なおこの記事は Ruby の知識を前提としないように執筆されており、Ruby の知識が必要となるところには注釈を加えて補足しています。 普段 Ruby を書かない方にも読んでいただければ幸いです。 問題を引き起こした変更 今回の問題は、RBS のメモリ使用量の削減を行っている中で遭遇しました。まずはどんな変更を行おうとしていたかを解説します。 変更の動機 最近私は RBS のメモリ使用量の削減に取り組んでいます。1 その取り組みの中で、RBS のパーサーが作
モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する - MonotaRO Tech Blog
こんにちは。 この記事では、2024/5/22に開催された「アーキテクチャを突き詰める Online Conference」で弊社CTOの普川がお話しした内容（ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する〜モノタロウ基幹システム刷新の実践例）を、現場目線から改めてご紹介します。 なお、本稿の執筆は頼と尾髙が分担しておりまして、途中で急に文体が変わったな？と違和感を持たれることもあろうかと思われますが、ご容赦いただけますと幸いです。 本稿をさらに深掘りするイベントを10/4(金)に開催いたします。 ご興味ある方はぜひご登録ください。 https://connpass.com/event/328360/ 問題領域は関連システムの密結合点 分割を試みる 最初のモデルを手に入れる レイヤードアーキテクチャに沿って実装 レイヤードアーキテクチャのメリット モデルを洗練させ
オーバーエンジニアリングしないために心がけていること - $shibayu36->blog;
オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが
技術選定で失敗しない、正解にする力 - クックパッド開発者ブログ
プログラミングが好きなエンジニアの渡辺です。 先日 TechMTG という社内のエンジニアミーティングの場でお話させて頂いたことを書いてみようと思います。 表題の「正解にする力」というのは様々な意思決定に適用出来るものとして考えていますが、今回は技術選定という観点でお話します。 技術選定というと、世の中のデファクトだとか、新しい技術だとか、社内で実績のある枯れた技術とか色々な理由や基準で選ぶのが良いと、至るところで言われていると思います。 選定時に議論が平行線にならないように、判断基準を設けるべきというのもあるでしょう。 これらは重要であり、検討、準備することは必要ですが、それに加えて「正解にする力」というのも重要なのではないか？という提案です。 まず、組織における技術選定とは「正解を選ぶ」ことではないと思っています。 これはその技術選定結果はその人個人についてまわるのではなく、組織として
プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog
カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上（複数スプリントにまたがるもの）の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください！」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ
トランザクションスクリプトはだめなのか?
トランザクションスクリプトはだめなのか? トランザクションスクリプトのことをだめなコード (可読性が低く、修正が難しく、修正で壊れやすい) の代名詞として利用している人がそれなりにいる気がします。私自身はトランザクションスクリプトだからだめだとは思っていません。実際のところどうなん? ってことで、久々にエンタープライズアプリケーションアーキテクチャパターン (PoEAA) を取り出して調べてみました。 トランザクションスクリプトはアンチパターンではない トランザクションスクリプトはアンチパターンではありません。PoEAA でもアンチパターンとして取り上げられてはいません。 P.116 より シンプルな場合には、ロジックをどのように体系化するのかまでは必要ない。もちろん、どのようなプログラムでも、ある程度合理的なモジュールとしてコードを構成する必要がある。 トランザクションスクリプトであって
トランザクションスクリプトパターンについて調べてみた - んだ日記
こんにちは、福岡でエンジニアをやってます、んだです。 今回のテーマは「トランザクションスクリプトパターン」です トランザクションスクリプトパターンが気になったわけ まず、トランザクションスクリプトパターンがなぜ気になったのかについてですが、案件でユースケース記述を元に実装してみたことがきっかけです。 ユースケース記述では、ユースケースが達成するためのシナリオを書いていきます。そして、ユースケース記述を元にロバストネス図を作成していきます。 実装段階では、ロバストネス図を参照しながら、手続きの流れに沿って業務手順をそのままコードに置き換えるイメージで実装しました。 言葉ではわかりづらいかと思うので、サンプルコードを↓で書いてます。 nda-desu.hatenablog.com 実装自体はロバストネス図で実装のイメージができていたので割とスムーズにできたのですが、時間を置いてふと考えたときに
ロギングで読みづらいコードをDomain Probeパターンで整理する - OpenWork Tech Blog
Photo by Jason Abdilla on Unsplash ビジネスロジック vs ロギング こんにちは。ウェブエンジニアの濱田です。普段の業務ではスマホアプリ用のAPIを開発する一方で、古くなったコードベースの改善にも取り組んでいます。 早速ですがビジネスロジックのロギング処理は言うまでもなく重要なことですよね。エラーを検知するためのログ、分析用のデータを収集するログなど、弊社でもさまざまなログを取っています。 一方でビジネスロジック中にログのためのコードが混在することで「コードが読みづらくなった」ことのある方は多いのではないでしょうか。 本記事ではDomain Probeパターンという設計手法を用いて、ビジネスロジックからロギングの責務を切り離し、見通しを良くする方法を紹介したいと思います。 もともとはコード設計等で著名なMartin Fowler氏のサイトで紹介されていて知
一躍話題「鍵垢しかないSNS」。天才たちに囲まれてしまった筑波大生の個人開発奮闘記【フォーカス】 レバテックラボ（レバテックLAB）
一躍話題「鍵垢しかないSNS」。天才たちに囲まれてしまった筑波大生の個人開発奮闘記【フォーカス】 2024年8月30日 筑波大学 情報学群 情報科学類 2年 n4mlz（ネームレス） 小学生時代にビジュアルプログラミング言語「Scratch」に熱中し、情報技術者を志すようになる。古典的AIを入口として機械学習にも興味を抱き、高校進学後は本格的なテキストプログラミング言語学習に取り組む。現在は情報科学について体系的に学びつつ、フリーランスでのWeb制作業務受託や個人開発に勤しんでいる。名前は、良いハンドルネーム案が思いつかず、ひとまず無名を意味するNamelessにしたのがきっかけ。あまり気に入ってはおらず、いずれ改名したいと考えている。 X GitHub snooze（n4mlzさんが個人開発したSNS） 2024年5月、「鍵垢しかないSNS」をコンセプトとする「snooze」というサービ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud
ADRを運用して3年経った僕らの現在地
How DoorDash Builds Robust Microservices
そのデータ連携、ホントにそれでいいの？ 〜データモデル分析の重要性を説く〜 / How to analyse data integration
難しいから面白い！医薬品×在庫管理ドメインの複雑性と向き合い、プロダクトの成長を支えるための取り組み / Initiatives to Support Product Growth
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
