「UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている」「キャッシュはアーキテクチャではない。単なる最適化だ」などの語録を生んだ「Goの父」とも呼ばれるロブ・パイク氏の「プログラミング5カ条」について、ネット上で話題となっています users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html Rob Pike's Rules of Programming (1989) | Hacker News https://news.ycombinator.com/item?id=24135189 パイク氏の「プログラミング5カ条」は以下。 ルール1：プログラムのどこで処理時間がかかるかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測
ソフトウェア設計のトレードオフと誤り
「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 正誤表 ここで紹介する正誤表には、書籍発行
はじめに みなさんこんにちは。Sansan事業部プロダクト開発部のiOSエンジニア荒川です。 以前はRDBMSの記事*1を寄稿し、好評いただいたこともあり、定期的に車輪の再発明系の記事を書いていこうと思います。 さて本日はタイトルの通り、VimやEmacsに代表されるターミナルで動作するインラインテキストエディタをGoで開発してみました。 ソースコードは以下のリポジトリに置いているため、ぜひ参考にしてください。 github.com 完成品 文字だけだとイメージも湧きにくいので、まずは完成品をお見せします。 最低限エディタの動きは出来ている、というレベルの完成度ですね🙏 特徴 1000行インラインエディタ 文字入力/挿入/削除 画面スクロール キーボードショートカット ファイル読み込み/保存 Goのコードハイライト機能 実装の方針 今回はただ開発するだけではなく、いくつかのこだわりポイン
はじめに 1992 年に POSIX でシェルが標準化されて以来、シェルスクリプトの数値計算に expr コマンドは使いません。expr コマンドを使って計算していたのは Bourne シェル（古い UNIX の sh）時代の話で、現在の POSIX sh （dash、bash、ksh 等）時代では数値計算に expr コマンドは不要です。今どきはシェルの機能だけで整数の計算を行うことができます。「今どき」って一体いつからだって話なわけですが……。 注意 シェルスクリプトでパフォーマンスの話をするとすぐに「他の言語で〜」という方がいますが、私はどんなことにでもシェルスクリプトを使えなんて一言も言っていません。パフォーマンスを気にしている理由は、そこが実際にシェルスクリプトのボトルネックになるポイントだからです。そもそもシェルスクリプトと一般的な言語は言語設計レベルで得意なことが違います。ユ
開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
データ統括部AI基盤部の竹村( @stakemura )です。本記事では、このたびリリースされた、自分の声をキャラクターの声に変換できるWebサービス VOICE AVATAR 七声ニーナ を支えるバックエンド技術についてお話しします。 本サービスはDelight Boardという部署横断型のプロジェクトにて、1000人を超える社員投票により自分の案がまさかの採択となったことがきっかけとなります。幸運にも、百戦錬磨のプロジェクトメンバーに助けられ今日のリリースを迎えましたが、採択当時は人脈も信用貯金も何もない入社一年目の思いつきにすぎず、言い出しっぺである自分の力不足によりタイトなスケジュールでの開発となってしまいました。本記事では、その限られた開発期間の中で、自分が何を考えて実装したかを中心にお伝えします。 サービングに求められる要件 七声ニーナの音声変換はブラウザから受け取った入力音声
こんにちは丸山@h13i32maruです。 僕は今、Ubie Discoveryで医療従事者向けのカルテエディタを作っています。人生で初めてContent Editableを使ってエディタを作ってるんですが、それがすごく楽しいです！というのも、エディタを作るには色々技術的な課題があります。例えば、テキストをパースするには？ASTからHTMLをビルドするには？パフォーマンスのよい更新方法は？などなど。それらの技術的な課題を解決していくのが単純に楽しいという感じです。また、車輪の再発明は極力抑えつつ、自分たちのプロダクトでやりたいことを実現できるような工夫もしています。 というわけで、今回はそんなエディタ作りで取り組んだ課題と解決策を紹介していきたいと思います。 （訳: 楽しかったので、誰かに聞いてもらいたい！） エディタの概要 メンテしやすいテキストパーサ - PEG.js メンテしやすいH
消す前提で機能を作ろう
どうも、株式会社プラハCEOの松原です 先日プラハチャレンジの参加者と雑談していた際に 消す前提で機能を作ると保守性が上がるかもしれない という内容に触れたので、思ったことを記事にまとめてみました。 企画には必ず切り戻し条件を明示する 少し話が脱線しますが、僕はエンジニアになる前はWEBサービスの新規事業企画を担当していて、当時所属していたチームではサービスに追加機能を立案するときは 何が起きたらこの機能を削除するのか という「切り戻し条件」がセットで求められていました。 例えば求人サイトの応募を増やしたいな〜と考えて新機能を立案するとしたら、こんな感じ： 機能概要：スマホ閲覧者にはフッターに応募ボタンを表示する 切り戻し条件：実験的に追加した画面の求人応募率が逆に5%低下したらフッターを削除する 機能を追加しているとき自分はサービスを改善しているように感じがちですが、正確には機能を追加す
日本に「過ぎたるは及ばざるがごとし」ということわざがあるように、海外のソフトウェア開発現場でも製品が必要以上に複雑化してしまう「オーバーエンジニアリング」という現象がしばしば問題になります。そんなオーバーエンジニアリングの原因や影響、防止方法について、ボイスチェンジャーアプリの開発会社・Voicemodで主任プロダクトマネージャーを務めるシモン・ムニョス氏が解説しました。 Overengineering can kill your product - Mind the Product https://www.mindtheproduct.com/overengineering-can-kill-your-product/ ソフトウェアエンジニアとしての経験を持つプロダクトマネージャーのムニョス氏によると、「ありもしない問題を解決するためのコードやデザイン」と形容されることもあるオーバーエン
ハードシングスを引き起こしたHype Driven Development(HDD) | HiCustomer Lab - HiCustomer Developer's Blog
Hype Driven Development(HDD) シード・アーリーステージのスタートアップの開発者のみなさん、こんにちは。突然ですが、ソフトウェア開発していますか？毎日設計しコードを書いていますか？私は毎日しています。毎日ビジネスドメインと向き合っております。今日はそんなみなさんに、弊社のソフトウェア開発の失敗談（ ハードシングスへの突入と脱出 の「根の深い技術的負債」を掘り下げる内容になっています）を共有します。この失敗からなにか参考になるものがあれば幸いです。 実際に起ったこと 2018年初頭にサーバレスとDDDの導入 弊社のHiCustomerサービスのアーキテクチャはサーバーレスとDDDを軸に設計されました。サーバーレス環境としては、AWS APIGateway、AWS Lambda、AWS DynamoDBを使ったAWS推奨の構成を採用しました。DDDはGolangを使用
はじめにTechnology Innovation Group 辻です。 秋のブログ週間の 4 本目です。 最近はアーキテクトとしてチームにジョインすることも増えてきました。より素早く、継続的にビジネス上の価値を提供するためにチームの開発生産性は重要です。チームの生産性を高めるために私が心がけているいくつかの内容を紹介します。 心がけ 開発上のボトルネックを取り除く コードべースの品質を保つ コードを読みやすくする 素早くレビューに取り組む、質問/相談にレスポンスする 体裁の一貫性を保つ 1.開発上のボトルネックを取り除く開発上のボトルネックになっているポイントを発見し、原因を特定し、対応する、ということです。一例をあげると以下のようなことです。 コードの責務がはっきりしておらず、改修時の影響が大きくなる。意図しない挙動になる そもそもテストコードがなく、機能仕様が満たされているのかわから
今年のLayerXの取り組みについて書こうとも思ったのですが先日下記の記事でまとめてしまったので、今回は開発生産性に大きな影響を与える不確実性についてのポエムを書いてみようと思います。 いうのも最近はプロダクト開発そのものよりも、複数の事業をより遠くからサポートしていく事が多くなりました。そのため具体的な取り組みよりも、その根底にある戦略が正しくあることをサポートすることが多くなりました。 この視点から開発生産性について書くことは多少普段と違う見方をEngineering ManagerやProduct managerの方へ提供できるのではないかと思っています。 特にプロダクト戦略面における不確実性は具体的な運用のHowより大きな影響を開発生産性に対して与える事が多いため、戦略と開発生産性ということについて触れていきます。 戦略と開発生産性我々が開発するソフトウェアは前提として顧客に価値を
拙作の Unity用DIライブラリ、VContainer の v0.9.0 では、ILコードをコンパイル時に生成することによるメタプログラミングの高速化が足されました。 Unity用DIライブラリ VContainer の 0.9.0 を撒きました。 コンパイル時IL生成による高速化機能をマージしました。(オプション) IL生成でさらに 当社比 3-6倍くらいは速くなりました。これできっと Unity用 DIコンテナでは完全に最速になったんじゃないかな-と思います。https://t.co/YkHXXgP7nD pic.twitter.com/NFUxvLVzKd— ハダシA (@hadashiA) 2020年7月26日 この機能をつかうと、Zenjectのデフォルトとの比較でディタ上では50倍くらい、IL2CPPでは20倍〜くらい速い結果になっています。 また、グラフのとおり VCont
builderscon tokyo 2019にゲスト(=聴講者)として参加しました。以下では、まず私が参加して特に興味深かったセッションについての感想を述べた後、総括を述べます。 セッションについての感想 Ruby (off|with) the Rails https://builderscon.io/builderscon/tokyo/2019/session/5acc1604-0f1f-493b-8025-364042db7123 Ruby on Railsを書いていてつらくなってきたときの指針についてのセッション。 内容は非常に面白く、明日から実践していこうという気持ちになった。 メタ的な感想ですが、「『問題を見極める→解法を与える」というフレームワーク」を冒頭で与えた後にそのフレームワークを使って「中規模Railsつらい問題」に対する解を提示する、というトークの構成が美しすぎて涙が
TR;DR useContext は、階層の深いコンポーネントに state を渡す場面で使うと良い useReducer は、state の変更パターンが多い場面で使うと良い useContext + useReducer は、state を使うコンポーネントの階層が深い上に、前回の state を元に新しい状態を作る場面で使うと良い useContextだけを使うケース useContext は React の組み込みの Hooks の1つです。Provider でラップしたコンポーネントのツリーのどこからでも、同一の Context Object を参照できるようにする Hook です。 useContext は Context を通じて子や孫以下のコンポーネントで同一の JS オブジェクトを呼び出せる Hook です。これにより props のバケツリレー （Props Drill
こんにちは、karahiyo(@karahiyo_n)です。 今回はZucksアドプロダクト事業本部における技術的負債返済との付き合い方とその変化の話になります。 事業としては10年目となり、今回取り上げる技術的負債を抱えているシステムというのはだいたい8年ものになります。8年間は今までのやり方でいい感じにやってこれたのですがシステムも人も事業も業界も変化し今までのやり方だけでは不十分ということで、今後も事業を支えられるシステムであり続けるためにもあらためて技術的負債について向き合いました。 tl;dr 技術的負債への対応観点で今うまくやれてること、自分たちの苦手なことを確認したら対策が見えてきた 必要だったのはチームで技術的負債についてコミュニケーションできるようになることと、負債の把握と管理 チームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が技術的負債の存在を認知し、特定
いつも心に省メモリ。どうも、かわしんです。今日はメモリアロケーションについてのポエムを綴ります。さらっと流してください。 ちなみに、ここでいう省メモリとはメモリサイズだけの話ではありません。 メモリをアロケート（確保）するとき、あなたはどんな感情を抱くだろうか？おそらく何も感じない人がほとんどだろう。というかメモリをアロケートしたことにすら気づいていないのかもしれない。 僕はメモリをアロケートするたびに心が痛む。本当はアロケートしなくてもいいのではないか、別のところでまとめてアロケートした方がいいのではないか？色々悩んだ結果、苦渋の選択としてメモリをアロケートするのだ。 メモリアロケーションのコストとは何か 僕がなんとなくメモリアロケーションに罪悪感を覚え始めた時、僕はメモリアロケーションのことを何も知らなかった。大きなメモリを確保するほどコスト（確保に必要な計算時間）が大きくなると思って
こんな悩みはありませんか？ なぜか忙しくてメインの仕事が進まない 人に任せられない仕事を常に抱えている 人に任せたは良いがうまくいかない 私はあります。日々仕事をする中で悩んでいます。その中で実践して、見つけたことを今日はお話します（まだまだ勉強中なのでフィードバックを貰えると嬉しいです）。 忙しいのは「見えない仕事」に追われているから です。 人に任せられないのは見えない仕事を定義しないから です。 ただしこの話は「手順書を書こう」という話ではありません。 むしろ手順書は無い方が良いです。 ではどう業務設計すれば良いのでしょうか？ それを説明します。 対象の人 業務要件定義や業務設計というと、かなりお硬い印象があるかもしれません。 実際に「業務設計」などで検索すると硬い組織での情報が多くでます。 でも私は小さな組織にこそ業務設計が必要だと私は考えています。 数人規模の組織を対象にしていま
技術的負債とどう向き合う？ 広木：では次のテーマにいきましょう。弊社の技術的負債について。デプロイパイプラインの自慢をさせてくださいってやつですね。どうでしょう？ 横路：マイクロサービスって「最初からマイクロサービスにするな」って言われるでしょ？ うちには育ち切ったモノリスがあります！ 広木：すばらしい！ 横路：ぜんぜん自慢できることじゃないんですけど。サービスが8個くらいあるんですが、最初の会計サービスは丸々と太っていて、もうフォアグラですね。だいたいRailsなんですが、クックパッドのコアの部分も相当じゃないですか。あれの半分くらいはあると思います。 なので、モデルもコントローラーの数もだいたい数千ですね。フロントエンドのコードも数十万から100万行くらいですね。それをこれからしっかりマイクロサービス化していけるのがうちの強みだと思ってます。 マイクロサービスが役立つのはだいたいあれで
あなたの新規事業プロダクト開発はこうして失敗する🦆
釣りタイトル容赦。なんてことありません、僕の失敗談です。 失敗談は好きですか？僕は大好きです。 他人の不幸はなんとやら。さぁ行ってみよう！ 1. 早すぎる最適化をしてしまう ドナルド・クヌース先生の、「早すぎる最適化は諸悪の根源」という言葉は、ソフトウェア開発に携わっている皆様であればそれなりに日々実感することであり、なんとなくでも直感的に共感できることと思います。 この言葉自体は、ソフトウェア開発の性能チューニングの文脈で語られるものだとは思いますが、僕はこの言葉、結構いろんな場面で使えると思いますし、使っています。 もちろん原義通り、パフォーマンスのための最適化という文脈でも当たり前のように意識したほうが良い言葉ではありますが、例えば抽象概念のモデリングや、コード品質の向上、ライブラリやアーキテクチャの選定といった場面でも使える概念ではないでしょうか。 「ここ」と「そこ」のロジックはな
「もっとうまくできるはず」出版社の販売サイトを無断で作ったオードリー・タンが“新しい仕事”を手に入れたワケ | 文春オンライン
私にとって、仕事とは常に新しいものを生み出す習慣です。仕事は創作の時間、生活はリラックスの時間、私の毎日はこの2種類の異なるリズムでできています。このリズムのどちらがいつ起こり、いつ停止するかはそのときの気持ち次第です。 気持ちは時間によって分けられるのではなく、空間によって分けられます。つまり、私は何時何分に仕事を始め、何時何分に退社するかにはこだわりません。しかし、私の休息空間にはキーボードがないので、この空間では仕事モードにならないのです。 早すぎる最適化は諸悪の根源 2008年頃、『ポモドーロ・テクニック(トマト時計管理法)』という時間管理法について書かれた文章を読みました。これは、1987年にイタリアの大学生、フランチェスコ・シリロが最初に発明した方法です。期末試験に向けて勉強していた時、時間がなくて追いつめられていたシリロは、集中するため、キッチンに置いてあるトマト形のタイマー
レンダリングの仕組みを知り、パフォーマンス向上に活かす
この記事について 勉強会で作成したスライドの内容を簡単にまとめる。 メモレベルですが、どうかあしからず。 主な内容 ・ブラウザのレンダリングの仕組みを把握する ・パフォーマンス向上に使えそうな小ネタの紹介 レンダリングの仕組み 大きく４つのプロセスに分けられる。 Loading Scripting Rendering Painting Loading HTMLやレンダリングに必要なリソースを読み込む。 主な仕事はDownloadとParsing。 Download HTMLを取得し、その中で参照されているリソースがあればそれらを読み込んでいく。 Parsing リソースをレンダリングエンジンの内部リソースに変換する(HTML→DOM Tree、CSS→CSSOM Tree) 構造が複雑になる程、解析に要する時間が増える。 ボトルネックになりがちなところ HTMLのパース中にscriptタグ
みんな大好きボブおじさんのClean Coderの6章にコーディング道場という項目があり、ここで、ボウリングゲームというTDDの実演ワークショップについて書かれています。これは本の中に記載されている以下のURLで今でも見ることができます。 http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata Clean Coder プロフェッショナルプログラマへの道 作者:Robert C. Martinアスキー・メディアワークスAmazon これは、ボウリングのスコア計算を題材にしたTDDの手習いです。しかし、これには今となっては問題があります。近年、ボウリングのスコア計算には、新しい計算方式も用いられ始めているからです。これは「カレントフレームスコアリング」呼ばれるものです。 このワークショップは2001年からなので仕方がありません。や
memo？ useCallback？ パフォーマンスが気になる JSXer には SolidJS がオススメ - Qiita
memo？ useCallback？ パフォーマンスが気になる JSXer には SolidJS がオススメJavaScriptTypeScriptフロントエンドReactSolidJS パフォーマンスなんか気にしたくない Give a man a bug and he'll work for a day. Give a man a benchmark and he'll work for a lifetime.1 https://twitter.com/awesomekling/status/1318615899910307850 パフォーマンスなんかに気をとられながら実装したくないんですよ。 React の memo() や useCallback() のような最適化のためだけの API を呼ぶ呼ばないで 1 ミリ秒も悩みたくないんです。そんな API は存在しないでほしい。 でも気に
HTMLパーサーの設計・実装ノート (1) 字句解析
ふと思いつきでHTMLパーサーを書いているので、どのようなことを考えながら実装したかの記録を残します。 (1) 字句解析 (2) 構文解析 おことわり 偏ったこだわりや早すぎる最適化もあるかもしれませんが、あくまで趣味で書いているものなのでご理解ください。そういったもののなかにも、他の人の発想のヒントになるものも含まれると考えています。 途中の試行錯誤のサイクルを省いて結論だけを紹介している箇所もあります。ご了承ください。 ソースコードは https://github.com/qnighy/htstream に上げていますが、現在のところ完成度はそれほど高くありません。ドキュメントもほぼありませんがご了承ください。 HTMLについて HTMLの管轄をめぐっては紆余曲折がありましたが、現在はWebブラウザベンダーを中心とする標準化団体であるWHATWGが制定するHTML StandardがH
「JX通信社Advent Calendar 2019」3日目の記事です.*1 昨日は, @kimihiro_nさんの「Scala で書いたマイクロサービスを Go で書き直した話」でした. 改めまして, こんにちは. JX通信社でエンジニアをしています, @shinyorke（しんよーく）と申します. 今年の10月に入社してから, CTO室*2のデータ・エンジニアとして基盤の構築から運用のサポートまで色々しています. ちなみに趣味は野球のデータ分析です.*3 入社後最初のエントリーとして, 私が好きかつ情熱を持って育てているデータ基盤の話を語りたい...ところですが！？ 入社してプロジェクト内でやった言語化は記録・知見として残しておきたい. 世の中, アジャイルなやり方・プラクティスは多数あれどデータ・サイエンスや分析という文脈での言及って案外少ない. チームメンバー以外からの評判も良かっ
テキスト生成 AI 利活用におけるリスクへの対策ガイ ドブック（α版） 2024（令和 6）年 5 月 30 日 デジタル庁 〔ドキュメントの位置付け〕 参考資料。今後、デジタル社会推進標準ガイドラインへの編入を検討予定 〔キーワード〕 テキスト生成 AI、生成 AI、サービス開発者、サービス提供者 〔概要〕 テキスト生成 AI を利活用し、行政サービスや職員業務の改善の重要度が高まる中、リ スクを特定し、そのリスクを受容できるレベルまでに軽減する対応もまた重要になってい る。テキスト生成 AI に関連するリスクは多岐にわたるが、その多くはテキスト生成 AI 固有 でない AI システム全般に共通するものである。そこで、本文書では政府情報システムを対 象に、テキスト生成 AI 固有と見られるリスクに焦点をあて、留意点を紹介する。現段階 （2024 年 5 月現在）では、実践的なフレームワー
はじめに 「推測するな、計測せよ」って誰が言ったの？という話。 「推測するな、計測せよ」という言葉があり、いかにも、「憶測で物を言うな」という文脈での逃げワードとして使われがち。しかしいかにも日本語的に語呂が良すぎるので、日本語話者以外であるであろう誰かの意図を、日本語で良いカンジにリメイクしたものだと「推測」していた。 似たところに「マッカーサー元帥の部下であり、日本の産業界に統計学的手法をもたらし大きな影響を与えたというデミング博士」の webサービスの性能改善や大企業に伝わるQC活動の文脈でよく使われる「計測なくして改善なし」*1、“if you can’t measure it, you can’t manage it.” もある。でもこの記事によるとそれも誤用とのことでとにかく諸説あるようだ。じゃあ「推測するな、計測せよ」is何。推測していないで調べました。 「推測するな」の起源
マジでちいさいセルフホストコンパイラ
マジでちいさいセルフホストコンパイラがほしい リポジトリ：https://github.com/sozysozbot/2kmcc hsjoihs「C コンパイラ自作においてセルフホスト達成はかなり分かりやすいマイルストーン」 hsjoihs「セルフホスト、たとえば構造体がほしくなるので構造体を実装するモチベができる」 hsjoihs「しかしながら、このゴールポストは、C で C コンパイラを書かない限り達成できない」 hsjoihs「そうだ、マジで小さい『セルフホストコンパイラ』を C で書いて、『それをコンパイルできたらすごい』にしよう！！！！」 hiromi_mi さんの hanando-fukui v1.1.1 が単一 .c で 2200 行、.h に 169 行 hsjoihs「@hiromi_mi hanando-fukui ってどんな機能があります？」 hiromi_mi「可変
Capistrano 3によるRails 5.2 + puma + nginxのデプロイをステップバイステップで学ぶ - Qiita
このドキュメントを書いた理由 qiita内も含め、同じような事例は数多く公開されているが、残念ながらイチから学ぶ上ではほとんど参考にならなかった。 なぜなら重要なのは、最終的な作業内容や設定ファイルの中身ではないからだ。それらはソフトウェアの構成やバージョンが変われば容易に変化する。 本当に重要なのは、デプロイ作業がどんなステップで成り立っていて、各ステップで何を目的とし、そのために最低限どんな設定が必要なのか、理解することだ。 そういうわけで、自分で考えて調べて実行したので、結果をまとめることにした。 方針 以下の6ステップに分割して作業を進めた。概ね、各ステップがCapistranoの一プラグインに対応している。つまり一つずつプラグインを追加していくイメージである。 ssh/gitによるファイルの配置 rbenvの動作確認 bundlerによるgemインストール Railsの設定 pu
メリークリスマス！ みなさんは、見てないアニメをネタにするなんてしてませんよね？ 私は「俺を好きなのはお前だけかよ」しか見てません。 さて、並行並列プログラミングを愛し、スレッドプールに日々感謝を捧げているみなさんは、 ValueTask を活用しているでしょうか？ 私は .NET Core 2.1 以降の ValueTask が大嫌いです。この嫌いという気持ちを、歴史を紐解きながら解説していきたいと思います。 ValueTask<TResult> の登場 最初の ValueTask である、 ValueTask<TResult> の登場は、 C# 7 と同時でした。 C# 7 では、 async/await が拡張され、ユーザーが新たに Task のような何か（DSL のために Task を拡張したり、コルーチンの仕組みを作ったり……）を定義できるようになりました。詳しくは、 ++C++
Paul Grahamによるエッセイ、「How to Get Startup Ideas」の公認日本語訳です。Paul GrahamはY Combinator（Airbnb、Dropbox、Reddit、Stripeなどを輩出したスタートアップ・シードアクセラレーター）の創設者です。プログラミング言語Lispの解説書や『ハッカーと画家』などを著したプログラマー、作家でもあります。彼の思考は論理が通っていて気持ちが良い。上の画像はPaul Grahamのツイートから引用しました。 4月17日、朝7時14分。ロンドンでこれを書いています。増加が止まらない感染者数と死者数の速報と、毎週木曜20時のNHS（イギリスの国営医療サービス）関係者への拍手を除き、繰り返される日々。上達していくドリップコーヒー。そんな静かなロックダウン（都市封鎖）生活を送っているうちに、長期プランを考え直す必要があると感じ
週刊Railsウォッチ（20191119後編）メソッド参照演算子が廃止、GitHub新機能続々、平成Ruby会議、GitHub OAuthバイパスほか｜TechRacho by BPS株式会社
2019.11.19 週刊Railsウォッチ（20191119後編）メソッド参照演算子が廃止、GitHub新機能続々、平成Ruby会議、GitHub OAuthバイパスほか こんにちは、hachi8833です。うらやましさに身を焦がしてます。 やってしまった（経済を回します）。 pic.twitter.com/0lj9zGNGL4 — hikalium (@hikalium) November 13, 2019 つっつきボイス:「この間出たMacbook Proの16インチね☺️」「買った人or買いたい人...はさすがにいないか😆」「税金抜きでこの値段はやっぱ高すぎ💸」「メモリ64GBはたしかに欲しいけど」「つかそこだけ欲しい😭」「Escキーがやっと物理に戻ったし」「名前がProなのにプロ仕様じゃなかったとは😆」 元記事: 16インチMacBook ProにESCキーが復活したのは
テキスト生成 AI 利活用におけるリスクへの対策ガイ ドブック（α版） 2024（令和 6）年 5 月 29 日 デジタル庁 〔ドキュメントの位置付け〕 参考資料。今後、デジタル社会推進標準ガイドラインへの編入を検討予定 〔キーワード〕 テキスト生成 AI、生成 AI、サービス開発者、サービス提供者 〔概要〕 テキスト生成 AI を利活用し、行政サービスや職員業務の改善の重要度が高まる中、リ スクを特定し、そのリスクを受容できるレベルまでに軽減する対応もまた重要になってい る。テキスト生成 AI に関連するリスクは多岐にわたるが、その多くはテキスト生成 AI 固有 でない AI システム全般に共通するものである。そこで、本文書では政府情報システムを対 象に、テキスト生成 AI 固有と見られるリスクに焦点をあて、留意点を紹介する。現段階 （2024 年 5 月現在）では、実践的なフレームワー
「へしこず」の rch850 です。ISUCON 10 の予選を nodejs 実装で通過しました。奇跡的な予選通過の ISUCON 5 以来、2度目の本選進出です。やったぜ！チームメイトは machosita と emittam です。いつもありがとうございます。 個人的には nodejs で予選を突破できたのがうれしいです。 nodejs への思いは最後に。 macoshita の予選レポートが実況風味なので、こちらは箇条書きにします。実況風味はまた時間があるときに。 なおリポジトリはこちらです。 github.com スコア推移はこう。 スコア推移。例年と違って早すぎる最適化を避けた結果、こんな推移になった #ISUCON pic.twitter.com/TSHmMosU7E— りちゃ🏠🌈 (@rch850) 2020年9月14日 やったこと サーバ構成 シンプルにこうしました。
全柔連が小学生の全国大会を廃止するという決定をしました。私は素晴らしい決断だと思います。なぜ若年層での全国大会を行わない方がいいのか三つの理由で説明します。 ①そのスポーツが弱くなるから ②全ての子供がスポーツを楽しめないから ③競技を超えた学びが得られないから まず若年層の全国大会が成人になってからの競技力向上に役に立っているかというとマイナス面の方が多いと考えられます。その理由の一つには早すぎる最適化があります。子供は大人のミニチュア版ではありません。例えば、子供は身体に対し頭が大きく、胴体も細いです。また体が小さいのになぜか子供は字を大きく書きます。それは筋の調整と連動がうまくいかないので細かい作業が苦手からです。その一方で立位のバランス自体は大人とそれほど変わらないぐらいうまくできます。 ということは子供の世代の柔道は勝利のためには大人時代とは違う戦略が求められるということです。早
【レポート】 プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ AWS-12 #AWSSummit | DevelopersIO
【レポート】 プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ AWS-12 #AWSSummit こんにちは。森田です。 本記事はAWS Summit Tokyoで行われたセッション「AWS-12 プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ 」のセッションレポートです。 セッション視聴 AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。） セッション概要 スピーカー アマゾン ウェブ サービス ジャパン合同会社 デジタルトランスフォーメーション本部 プロトタイピングエンジニア 友岡 雅志 氏 セッションで取り上げること AWS でプロトタイピングを効率的に行うノウハウ 業界に依らず普遍的に役立つ知識 前提知識 CI/CD、自動化テストなどといったモ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に
Goで作るテキストエディタ - Sansan Tech Blog
今どきのシェルスクリプトは数値計算にexprを使わない（POSIX準拠） - Qiita
“Tao of Node - Design, Architecture & Best Practices” 日本語翻訳
七声ニーナを支えるバックエンド技術 | BLOG - DeNA Engineering
Content EditableでWYSIWYGエディタ作るの楽しい！ - maru source
余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは？
チームの開発生産性を高めるための心がけ | フューチャー技術ブログ
プロダクト拡大と開発生産性｜Matsumoto Yuki
Unity界最速DIコンテナVContainer が速い理由の解説 - @hadashiA
builderscon tokyo 2019の感想 | さんちゃのブログ 2nd
useContext + useReducer の使いどころ - パンダのプログラミングブログ
技術的負債との付き合い方とその変化 - CARTA TECH BLOG
メモリアロケーションに対する罪悪感 - kawasin73のブログ
仕事を人に任せられず忙殺されてる人へ: 小さな組織向け業務設計の方法
技術的負債とどう向き合っているか？ ITベンチャー4社が語る、開発チームのリアルな裏側 Part3
一体いつからボウリングのスコア計算方法が一つだけだと錯覚していた？ - An Epicurean
データをいい感じに活用する文化を育てる - アジャイルな言語化とその取り組み - JX通信社エンジニアブログ
テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版）
「推測するな、計測せよ」を推測するな - Qiita
私、ValueTaskは限定的でって言ったよね！ - アジョブジ星通信
スタートアップのアイデアを得る方法（ポール・グレアム）｜Kakinoki Masa, PhD
テキスト生成 AI 利活用におけるリスクへの対策ガイドブック（α版）
ISUCON 10 予選を nodejs 実装で突破しました（へしこず） - rch850 の上澄み
若年層での全国大会がなぜ良くないか｜DaiTamesue為末大