Akihiro Komori @comocc コーナンの作業台買ったんです。薄い鉄板で出来ててコストカットの鬼みたいな雰囲気。なんだけど、この脚のプレスの入れ方をみて驚いた。これどんな神が設計したんですか?この加工だけで強度と安定性爆上がりですよ。大学は機械系だったけど、こんなの授業じゃ習わなかったなあ。惚れ惚れする。 pic.twitter.com/vMDuBeXdJ6 2024-04-17 10:32:24
Akihiro Komori @comocc コーナンの作業台買ったんです。薄い鉄板で出来ててコストカットの鬼みたいな雰囲気。なんだけど、この脚のプレスの入れ方をみて驚いた。これどんな神が設計したんですか?この加工だけで強度と安定性爆上がりですよ。大学は機械系だったけど、こんなの授業じゃ習わなかったなあ。惚れ惚れする。 pic.twitter.com/vMDuBeXdJ6 2024-04-17 10:32:24
ポエム特化のZenn2との噂の「しずかなインターネット」を使いはじめたので、ユーザーとしてどんな技術が使われているのかを確認していく。 sizu.me おもむろにbuiltwith.comにかけてみる。 builtwith.com ここで分かる情報はブラウザのDevTools眺めてても得られるのであまり収穫はない。 前段にCloudflareのCDNサーバーがいて Next.jsで生成されたレスポンスを返している ことがわかる。 この時点ではキャッシュのみCloudflareなのか、Pages/WorkersでNext.jsのSSRごと動かしているのかは判断できない。 認証 Set-Cookie: __Secure-next-auth.session-token=が含まれているのでNextAuth.jsを使っているのが分かる。 next-auth.js.org Emailでサインアップする
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
みん@機械探求者 @mins2k 設計に現場スケッチしてもらったブラケットを取り付けに行ったのだが、、、微妙に穴位置が合わない! 私「部品つきませんよ、ピッチ違うよ、何で?」 設「あー、、測ったらキリの良い寸法じゃなかったので四捨五入しましたけど、、」 四捨五入、、四捨五入?、、四捨五入!? 2023-10-17 17:34:46
🔋 Greener batteries ♻️ More recycling 🚯 Less pollution The Council has adopted today new rules that will, for the first time ever, cover the whole life cycle of batteries. The goal is to make batteries sustainable while keeping the sector competitive. 👇 — EU Council (@EUCouncil) July 10, 2023 今回欧州評議会が採択した新たな規制は、バッテリーの製造からリサイクルまでのライフサイクル全体を見直し、循環型経済を促進することを目的にしているという。そのなかで、家電製品などに搭載されるバッテリーについて、
MIXI(旧社名ミクシィ)は5月8日、同社の新入社員向け技術研修で使用した資料を無償公開した。分散型バージョン管理システム「Git」とテスト・設計研修の資料をスライド共有サービス「Speaker Deck」で公開中。動画も後ほど公開するという。 Gitの研修資料は約470ページあり、Gitを使ったチーム開発の進め方やGitの内部構造などを記載している。テスト・設計研修の資料は約40ページ構成で、テスト技法やコードレビューのコツなどを紹介。いずれの資料も同社の社員が作成した。 同社は2021年から新入社員向け研修の資料を一般公開しており、22年はUnityでのゲーム開発やAI、セキュリティ研修など全12種類の資料を自社ブログに掲載していた。同社の公式Twitter(@mixi_engineers)は「今後も随時資料や動画を公開していく」としている。 関連記事 ミクシィ、技術カンファレンスを初
はじめに アーキテクチャ・デザイン全般 ソフトウェアアーキテクチャの基礎 Clean Architecture 達人に学ぶソフトウェアの構造と設計 Design It! ソフトウェアシステムアーキテクチャ構築の原理 データ指向アプリケーションデザイン マイクロサービス マイクロサービスアーキテクチャ マイクロサービスパターン 実践的システムデザインのためのコード解説 ソフトウェアアーキテクチャ・ハードパーツ ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 現場で役立つシステム設計の原則 要件定義 はじめよう!プロセス設計 ~要件定義のその前に はじめよう! 要件定義 ~ビギナーからベテランまで はじめよう!システム設計 ~要件定義のその後に Web, Web API Webを支える技術 プロになるためのWeb技術
あけましておめでとうございます! 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
とても長くなりました。10,000字を超えています。 途中で読み疲れちゃうようだったら、ブックマークなどを利用して、分けて読んでいただけると幸いです。 なにがあったのか、まず事実関係を確認「売れなかった」からではない。一部の論者は「MRJはユーザーのニーズに合っていないから失敗した」とかいう誤解をしているようですが、そうではありません。ニーズに合っていたか、よい飛行機だったか、という問題ではないのです。旅客機の開発はお金と時間がかかるので、最初に「見込み客」との契約を行い、それが成立した時点で開発を決定するのです。この顧客を「ローンチ・カストマー」と言います。 MRJの場合、ローンチ・カストマーは全日空でしたが、開発が進むにつれて海外からの発注も獲得しており、将来的に採算がとれるかどうかは別として、「顧客ニーズに合わない」的外れの製品ではありませんでした。 もちろん、これから開発する飛行機
技術者はよく、実装可否の問い合わせに対して本当はやりたくない・すべきでないと思っているのにやればできることだからと「技術的には可能です」と答えてしまいハマる⋯って本当ですか? 私は最低でもここ10年は「技術的には可能です」と発言した記憶がありません。なぜそう言うことがないかというと、可否の問い合わせを受けた時点で次のようなことを考えてしまうからです。 運用は回る? 人力操作が絡むフローがあるけど利用数が増えたときにちゃんとスケールする? 休日深夜対応が必要になりそうだけど要員と人件費コストは確保できてる? カスタマーサポート対応激増しそうだけど(以下同文 誤操作があったりしてデータの修正依頼が来たときに訂正しようがない要件っぽいけど大丈夫? エンジニアがDB直操作対応するサービスメニューが存在するけど事故リスク、工数コスト、今後の開発停滞リスクは織り込み済み? 事故の際の責任はエンジニアに
この機械ボタン押し続けな動かんな。せや!こうやったら押しっぱなしにできるで。生活の知恵や→こうして重大事故が起きる - Togetter フォロー・ブクマ外からクソリプ失礼します。 フールプルーフ機構を回避した結果、重大な事故が起き、更にはその回避方法によってそれが悪化するというシチュエーションについて話す場であるという前提のもとに、フールプルーフ機構の設計自体に問題がないかを設計者は考えるべきではないかという問題定義をさせて頂きます。 まず前提として、フールプルーフ・フェイルセーフを搭載しようとする判断自体は極めて正しいと思っております。 使用者に対して「完全に説明書を読み込み常に無限大の集中力を発揮すること」を求める設計は双方完全合意の極めて特別な場合以外は推奨されない設計であり、もし作る側が使用者に対してこのようなことを何の相談もなしに安易に求めるのならばそれはモノづくりとしては不誠
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
USBが誕生したのは「奥さんのプリンタをつなげる手間にキレたから」 USBの設計当時を振り返る:“PC”あるいは“Personal Computer”と呼ばれるもの、その変遷を辿る(1/6 ページ) IBM PC、PC/AT互換機からDOS/Vマシン、さらにはArmベースのWindows PC、M1 Mac、そしてラズパイまでがPCと呼ばれている昨今。その源流からたどっていく大原雄介さんによる解説連載の第8回。前回はPCのアーキテクチャを巡るIntelとMicrosoftの動きを描いたが、今回はそこでIntelの取り組みの成果の一つとして挙げたUSBのお話である。 USBはいろいろ失敗もある(というか、現在進行形で失敗し続けている気もしなくはない)が、それでも大成功したインタフェースである。そして単にPCだけではなくマイコン(※1)などでも普通にサポートされるようになってきており、加えてP
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く