11月のブラックフライデー／サイバーマンデーセールもあり、今年もMac appを中心にいろいろなソフトウェアを導入してみました。中にはきっと使わなくなってしまうものもありそうですが、これは使う使わないだけでなく、実装されているUIの研究をする目的だったり、あるいは単にクリエイターへの「応援」としてでもあったりします。いくつかピックアップしてみます。 Procreate Dreams (iPad)Procreate DreamsはiPadOS向けの2Dアニメーション制作ソフトウェアです。iPadで一番有名なお絵かきソフトウェアの一つ、Procreateを作っている会社が新たにリリースしたアプリケーションです。 私はアニメーション制作をやるようなクリエイターではないのですが、Procreate DreamsはとにかくUIがよくできていて、まずワクワクしてしまったというのもあるのですが、やっぱり
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経
読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する：「単体テストの考え方（UTPPP）」を読む（後編） - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分：UTPPPを読む（前編） - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ
「ソフトウェアアーキテクチャの基礎」読書感想
2010年代を乗り越えてきた経験者が読むと良さそうという噂を聞いたので読んでみた。 内容まとめではなく感想です。各章のタイトルだけは丸々記載してますが、目次として上記ページで全て公開されているものです。 ちなみにこれ書いている私はソフトウェアアーキテクトではなく、フロントエンドアプリケーションの設計を担当するテックリードぐらいのレイヤーです。この書籍の中でいう「開発者」です。 業務ではフロントエンドアプリケーションの設計・実装をしています。 全体的な感想 1章（イントロダクション）、22章（効果的なチームにする）、23章（交渉とリーダーシップのスキル）が特によかった。 やっぱ "結局人" の部分が刺さってしまう。 心に書きとめておきたい3つを挙げるとしたら以下。 ソフトウェアアーキテクチャとは「構造」「アーキテクチャ特性」「アーキテクチャ決定」「設計指針」の4つから成る 「一見どう見えよう
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず
イギリスの政府当局が子持ちの親御さん向けに配布した「子どものPCに入っていたら注意すべきソフトウェアリスト」が、あまりにハイレベル過ぎるということでインターネット上で話題になっています。 話題になっているのはTwitterユーザーの＠G_IWさんがツイートした以下の画像。 This utter crap is being distributed through schools from the 'local authority' so presume @WalsallCouncil today. The level of disinformation is staggering. I'd be proud to find my kids learning to use any of these. Except Discord but that's nothing to do with ha
文化からツールまでを扱ったタイトルに違わぬ大著『Googleのソフトウェアエンジニアリング』を読んだ - こまぶろ
昨年11月末に発売された『Googleのソフトウェアエンジニアリング』を読みました。 Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 細かい内容についての感想はTwitterの方に放流しているので、ブログでは簡単に。 とりあえず一周した。17章以降は基本「いやーGoogleさんすごいっす」という感じだったが、ところどころ役立つ話があったし、「エンジニアリングを発展させていった先の一つの形がこうなのか」という面白さは大きかった。逆に前半は実践的にかなり勉強になったのでちゃんと復習しよう…… #swebookjp— こま (@koma_koma_d) 2022年1月3日 全体の構成 書籍全体の構成は、以下のようになっています。 分量としては、「第4部 ツール」が最も大きな部分を占めています。 第2部から第4部に
GitHub - tadashi0713/howtheytest-jp: 日本のソフトウェア企業のテスト・テスト自動化に関する資料をまとめています
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ITエンジニアの課題解決能力を社会にインストールするために、2020年2月に発足したコミュニティ、ハッカーライフラボ。第4回目のオンラインイベントは、2019年10月に刊行された『ソフトウェア・ファースト』の著者である及川卓也氏が「ソフトウェア・ファースト」の考え方、日本企業の課題などについて紹介します。4回目の最後は、どうすれば組織は変わるのか、大企業を経験してきた及川氏ならではの理論に注目です。 組織を本当に動かそうと思ったならば、いろいろやりようもある 岩切晃子氏（以下、岩切）：今質問でね、「やっぱりトップはソフトウェアの重要性を認識してるんだけど、ミドルマネージャーが変化の障害になることが多いように感じる」と。「及川さんがミドルマネージャー層にメッセージを伝えるとしたら、どんなものを伝えますか」と書いてくれた人がいたんですけど、やっぱりこれも辞める気になって「変えるのか？」というの
ソフトウェアアーキテクチャ入門
はじめに 今回の記事では、ソフトウェアアーキテクチャの入門的な内容を解説する。 対象とする読者 ソフトウェアアーキテクチャを勉強するエンジニア アーキテクチャに関して全くわからない初心者 タイトルで気になったひと ソフトウェアアーキテクチャとは？ ソフトウェアのアーキテクチャは、システムの主要なコンポーネント、それらの関係（構造）、およびそれらがどのように相互作用するかを記述する。ソフトウェアのアーキテクチャとデザインには、品質属性、人間のダイナミクス、デザイン、IT環境など、多種多様な寄与要因が含まれる。アーキテクチャは、品質、保守性、パフォーマンス等のような全体的な成功に影響を与える重要な決定を含む。 ソフトウェアアーキテクチャの主な目的は、アプリケーションの構造に影響を与える要件を特定することだ。良好なアーキテクチャは、技術的な解決策を構築する際のビジネスリスクを削減し、ビジネス要件
良いソフトウェアとコードレビュー / Good software and code review
Scala + Caliban で作るGraphQL バックエンド / Making GraphQL Backend with Scala + Caliban
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。（2023年6月現在） ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
マイクロソフト、Excel関数ベースのローコード言語「Power Fx」をオープンソースで公開。さまざまなソフトウェアでの採用が可能に
マイクロソフト、Excel関数ベースのローコード言語「Power Fx」をオープンソースで公開。さまざまなソフトウェアでの採用が可能に Power Fxはマイクロソフトにとって初めてのローコード開発向けのプログラミング言語です。 Power AppsやPower Automate、Power BI、Power Virtual Agentsなどから構成される同社のローコード／ノーコード開発ツール製品群「Power Platform」のロジックの記述に用いられるプログラミング言語として、今年の3月に発表されました。 Introducing Microsoft Power Fx, a single computer language for logic customization across the #PowerPlatform. Learn how you’ll be able to go
書籍「ソフトウェアテスト技法ドリル」ではテスト設計の考えとツールの使い方まで学べちゃいました | DevelopersIO
私は開発寄りのエンジニアであり、テストやQA専門の方と同じチームで頑張る機会が少なかったのですが、「なるほど、こうやって考えて、こういうツールを使っているのか」と非常に勉強になりました。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。 最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。 とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの？ 本職のテスト
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog
今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し
ソフトウェアテストの学び方に関して書籍やウェブサイト、そしてそこから伸びる某かについて自分なりにまとめ直してみるかーと。思いました。これを全部読めとかではなくて、まぁ自分が今まで読んできて役に立ったものリストくらいの感じです。 また、このリストの解説をスクフェス新潟でプレゼンしたいと思い公募に出しました。リンク先でLikeしてもらえるとプレゼンできる確率が上がるのでよければぜひ押していってください。 ソフトウェアテストで参考にしている67のモノ #scrumniigata https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16369/67 まずは、リストを。後半に各カテゴリの所感とかを。 発端は先日、Twitterでリプライをいただいて、7年近く前に「テストエンジニアの品格」という煽ったプレゼンをしていた
1年半のソフトウェアエンジニア長期インターンで出会ったオススメ本をたくさん紹介します - Qiita
イントロ ABEJAアドベントカレンダーの4日目に一昨日飛び込みました、長期インターン生の佐藤(Twitter: @TodayInsane)です。 去年は機械学習を通して、TWICEというK-POPグループへの愛を語りました。 ABEJAには昨年4月、「本当に何も出来ないけど、休学してプログラミングとかエンジニアの経験を積みたいんです」という何とも不安な主張をするぼくを受け入れていただきました。 この1年半のエンジニア / リサーチ両インターンの過程で出会った良い本をどしどし紹介します。 ちなみにインターン開始時は プログラミング、Pythonだけならちょびっと書けます！(ABCのB問題とか機械学習ライブラリの写経) HTMLってどんな風になってるんですか？(？) サーバ...？？リクエスト...？？ JavaScript、名前は聞いたことあります 英語の論文しんどい、2時間ぐらいかけてI
本ブログ「Lean Baseball」開設10周年企画*1かつ, ちょっとした近況報告となります. お世話になっている皆様へ(TL;DR) 東京（の西側*2）で家を買いました, 引っ越しました. この決断とオチ, 未来に至るまで, 自分のキャリアとアウトプット, そしてこのブログは不可欠でした. 現職から前職以前の同僚（元同僚）, アウトプットや色んなことを応援してくださった皆様そして何よりも家族と友人に心から感謝御礼申し上げます🏚 お祝いはこちらからお待ちしています. 44歳独身ソフトウェアエンジニア、家を買う。 作業環境（まだ作ってる最中） こちらが購入したお家...で最初に作った作業環境です💻*3 （人生の一般的なアレとして）「家を買う（家の主となる）」事は一つの大切なライフステージのイベントなので, お世話になっている皆様へ(TL;DR) 44歳独身ソフトウェアエンジニア、家を
がくり（ソフトウェア関連垢） on Twitter: "昔、Googleのテスト自動化マネージャみたいな人が、日本に招待されて講演後、 日本人「コスパ悪いのをどう解決してますか？」 Google「解決していないです」 日本人「え！？」 Google「？」 日本人「コスパ・・・」 Goo… https://t.co/mWGWIQ7H9p"
昔、Googleのテスト自動化マネージャみたいな人が、日本に招待されて講演後、 日本人「コスパ悪いのをどう解決してますか？」 Google「解決していないです」 日本人「え！？」 Google「？」 日本人「コスパ・・・」 Goo… https://t.co/mWGWIQ7H9p
600ページ以上あり結構長いので方針としては第１部だけは一通り読んでみて、その先は各章結論から読んでいき、気になった部分だけ遡って拾い読みしていく戦略でいく方が良さそう。
2021.02.02 一般社団法人コンピュータソフトウェア協会(CSAJ) 一般社団法人コンピュータソフトウェア協会（略称「CSAJ」、東京都港区赤坂）は、各種メディアで報道されている、クラウドサービス「GitHub」について、正しい理解と対応に向けた文書を発表いたしました。 はじめに 各種報道のとおり、ソフトウェアのソースコードをホスティングするクラウドサービス「GitHub」において、大手金融機関の業務システムのソースコードの一部が公開されていた事象が発生しました。クラウドサービスにおいては、情報の公開範囲などの設定の誤りが、セキュリティインシデントにつながることがあり、利用においては十分な配慮が必要です。その上で、クラウドは危険であるので使わせないという判断にならないよう、GitHubをはじめ、外部のクラウドサービス利用の萎縮につながらないよう、各社の節度ある情報セキュリティ設計を要
先日、某VC投資先の方々に対して、「ソフトウェアエンジニアの採用時にコーディングテストをやりたいがどうしたら良いか？」ということについて語ってきたので、こちらにもエッセンスをまとめたいと思います。 コーディングテストの目的 なぜ我々はコーディングテストをやるのでしょうか？ もちろん、第一目的はソフトウェアエンジニアの採用候補者のスキルを見極めるためです。 過去に、経歴も良さそう、技術的な議論もスムーズにできる、なのにコードが書けない候補者に、私は何度か出会っています。「コードが書けない」のレベルは、（ある程度易しい）論理をプログラムに翻訳できず、まともな if 文が書けないというレベルを言っています。熟練者でもド・モルガンの法則をうっかり間違えるぐらいはあると思いますが、そういう話ではありません。コードが書けない候補者は、そもそも条件が書き下せません。このような候補者を雇ってはいけません。
OKIは、LINE Pay株式会社（代表取締役社長：前田 貴司、本社：東京都品川区、以下LINE Pay社）が提供する送金サービス「LINE Pay かんたん送金サービス」と連携できるソフトウェア開発キット（以下「LINE Pay送金SDK」）を金融機関向けに販売します。本商品は、同サービスとの連携に必要なプログラムをパッケージ化したもので、「LINE Pay かんたん送金サービス」の通信方式や暗号方式などを意識することなくアプリケーション開発を行うことが可能です。また、従来ゼロから開発しなければならなかった通信や暗号などのプログラム開発および単体試験を削減し、開発を簡略化することができます。金融機関は、運営している公式スマートフォンアプリからLINE Payに直接送金ができる「LINE Pay 残高送金機能」を容易に実現できます。 キャッシュレス決済の利用は近年広く浸透してきており、今後
Forkwell Library #14 2023.1.25 のスライドです。 https://forkwell.connpass.com/event/271212/
ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers
「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の輪読会のススメ - そーだいなる輪読会キックオフ / soudai-kickoff
Linearは、Asana以上の機能とJira以上の使いやすさとレスポンスの良さを実現する、タスク管理ソフトウェアを開発している。現在はクローズドベータテストを行っており、2021年に正式版のリリースを目指す。今回はCo-founderのTuomas Artman氏に話を聞いた。 ウィークリーユーザー2000人、参加企業700社のクローズドベータ運用中 ――まずはLinearについて教えてもらえますか。 Linearは、AsanaやTrelloなどの、タスクをチームメンバーに割り当て、その進捗状況を管理するためのツールと、Jiraのような、ソフトウェア開発プロジェクトの中期計画、追跡、管理を実行できる多機能ツールの中間的な存在となることを目指しています。 小規模なエンジニアチームをターゲットに開発を始め、現在はクローズドベータテストを行っています。ベータテストには、約700社が参加しており
【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で
(ゲームの話は一切知らん) いつのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別の事情をどうやっていくかみたいな話しか残ってないように見える。 端的にいえば、宣言的UIとkubernetesは聖杯だったのではないかな。 k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るときに宣言的UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成が定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語でソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねー
読書をしていると、書籍に記された新たな知識や考え方を取り入れることが可能で、時には人生に影響を与えるほどの印象深い書籍と巡り会えることもあります。世界に無数に存在する書籍の中でも「ソフトウェアエンジニア人生を変えた5冊の書籍」をネオバンク「Nubank」のソフトウェアエンジニアであるジュリアーノ・リマ氏が紹介しています。 Five Books that Changed My Career as a Software Engineer https://julianogtz.github.io/my-personal-blog/posts/five-books-that-changed-my-career-as-a-software-engineer ◆1：情熱プログラマー ソフトウェア開発者の幸せな生き方 リマ氏は、人生を変えた書籍の1冊目として「情熱プログラマー ソフトウェア開発者の幸せな
chriskiehlのブログより。 考えを改めたもの 過去の自分なら言い争っていたであろうことが、今では信じられるようになったこと。 様々な経験レベルを持つ人がいるチームで仕事をする場合は、型付き言語の方が適している スタンドアップは、実際に新人を注目するのに役立つ スプリント・レトロスペクティブは、実際の軌道修正のためのものであって(「つまり、なんてこった、うまく行かなかった!」)、皆の時間を無駄にするようなアジャイル/スクラムマスター的なものでない限り、その場に相応しいものである ソフトウェア・アーキテクチャは、おそらく他の何よりも重要である。優れた抽象化のクソみたいな実装は、コードベースに正味の害を与えません。悪い抽象化や欠落したレイヤーは、すべてのものを腐らせる Javaはそれほどひどい言語ではない 巧みなコードは通常、良いコードではない。明瞭さは、他のすべての懸念事項に勝る どん
DevOpsDays Tokyo 2021 https://confengine.com/conferences/devopsdays-tokyo-2021/proposal/15184/8
ソフトウェアエンジニアとしてモナドを完全に理解する / make-perfect-sense-of-monad
モナドを完全に理解する
「プログラマーのための CPU 入門 ― CPUは如何にしてソフトウェアを高速に実行するか」を読んだ - おしぼりの日常
年明けの暇な時間を利用して読んでみました。 書籍のリンク 技術書としての感想 良かった点 悪かった点 注意点 総評 技術書としての感想 良かった点 とにかく文章が分かりやすい 色々な用語の使い方に違和感がない 言葉にすると簡単ですが、本当に分かりやすかったです． 具体例が豊富 図が豊富 コード例が豊富 実験例が豊富 まず、「〇〇 な場合に命令の処理が詰まって遅くなります」といった説明の後に、「では、具体的にこういったケースを考えてみましょう」という具体例を持ってくる展開が多く、とても親切だと感じました．また、このような具体例の説明のときにほぼ必ず図が用いられています．特に全体を通して頻繁に出てくる命令流の図は非常に分かりやすかったです．また、コード例とそれを用いた実験も豊富でした．具体的には、キャシュの章では実際にキャッシュミスを意図的に起こすコード・キャッシュヒットを意図的に起こすコード
Innovative Tech： このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 アクタスソフトウェア（東京都新宿区）の坂下秀 代表取締役（以下、坂下氏）が発表した「コロナ禍において，小規模ソフトウェア会社での在宅勤務移行時に発生したさまざまな事象の報告」は、社員全員がテレワークを余儀なくされたソフトウェア会社が経験した多様な事象を時系列に記載した報告書だ。 同社は取締役含め社員6人、ソフトウェア開発を主な業務とする2003年創業の小さなチームだ。そんな小規模な会社が新型コロナウイルスの拡大に伴い、2020年初めからテレワーク環境に移行し、2021年初めには全従業員が在宅勤務となった。 決定当初の坂下氏は、技術面からは在宅勤務の実施に大きな問題はないと考えていた。自分で
多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今年導入したソフトウェア、魅力的だったソフトウェア（2023）｜usagimaru
モダンなソフトウェア設計の書籍 - kawasima
メンテのいらないソフトウェア - 誰かの役に立てばいいブログ
ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
政府当局が配布した「子どものPCに入っていたら注意すべきソフトウェアリスト」がハイレベル過ぎると話題に
組織を本当に動かしたいなら、やりようはいくらでもある 及川卓也氏が語る「ソフトウェア・ファースト」で変わる日本の企業
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata｜kyon_mm
44歳独身ソフトウェアエンジニア、家を買う。 - Lean Baseball
Googleのソフトウェアエンジニアリング - 技術メモ
GitHubに関する対応とお願い | CSAJ 一般社団法人コンピュータソフトウェア協会
ソフトウェアエンジニア採用におけるコーディングテストのススメ - MAYAH
「LINE Pay かんたん送金サービス」と連携できるソフトウェア開発キットを金融機関向けに販売｜プレスリリース｜OKI
ちょうぜつ改め21世紀ふつうのソフトウェア設計
エンジニアが作る、エンジニアが“使いたがる”タスク管理ソフトウェアLinear
ソフトウェア開発の進歩完全に止まったような気がする
現役プログラマーが選ぶ「ソフトウェアエンジニア人生を変えた5冊の本」とは？
業界6年目で考えが変わったソフトウェア開発のトピック
文化的負債との戦い: 老舗ソフトウェア開発会社でアジャイル変革を仕掛けた8年間
全社員6人がテレワークへ移行したソフトウェア会社に起きた実録トラブル集
多重下請けでは構造的にいいソフトウェアが作れない - きしだのHatena