タグ

ソフトウェアに関するombranのブックマーク (15)

  • ソフトウェアに関わる人が知っておくといいかもしれない法則10個

    「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション)」という興味深いポストをX(旧Twitter)で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション) コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物

    ソフトウェアに関わる人が知っておくといいかもしれない法則10個
  • CTO から見た,なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck

    Speaker Deck This deck requires a password Password

  • ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ

    あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2目の更新です。 ky-yk-d.hatenablog.com さて、題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな? 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも

    ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ
  • ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える

    ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により

    ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える
  • ソフトウェアエンジニアとして家を建てる仕事をはじめました

    まさかソフトウェアエンジニアの自分が業で家を建てる仕事をするとは思っても見ませんでした。2年前、DeployGateの米国オフィスを自分で施工した事をきっかけに声をかけてもらい、以来、技術アドバイザーとして携わらせて頂いていた米国の建築スタートアップ「HOMMA」に格的に参加し、ソフトウェア・アーキテクトとしてアメリカでスマートハウスをソフトウェア面から設計して家を建てる仕事をはじめました。趣味電子工作から初まり、深センでの独自設計ハードの少量生産、アメリカでのオフィスの施工と来て、次はまさかの物の建売住宅の開発です。プログラミングの傍ら取り組んできた物理的な「ものづくり」のサイズがどんどん大きくなってきて楽しい限りです。制御用のファームウェアやアプリ、Webシステムを書きながら、ヘルメットを被って建設現場で大工職人さんへ施工の指示出しをしたり、信号線や電力系統の配線を設計して建築

    ソフトウェアエンジニアとして家を建てる仕事をはじめました
  • ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita

    ソフトウェア開発の様々な局面で役に立つ、心理学的現象や行動経済学についての知識です。 経験則で把握済の事柄もあるかもしれませんが、 言語化して名前を与えることで何かのときにスッと出せたり、周囲の方々と議論しやすくなったりすると思います。 以下の3つの分類で記載いたします。 打ち合わせやチームワークに役立つ知識 設計やプログラミングに役立つ知識 メンタルヘルスケアに役立つ知識 打ち合わせやチームワークに役立つ知識 自己効力感 自己効力感とは、自分には何かを達成する能力がある、と信じる感覚です。 自己効力感が形成されていると、仕事の意欲が増したり、効率が上がったりします。 「この仕事は絶対ムリ~(>_<)!」と感じている仕事についてやる気がわかなかったり進捗が出なかったりするのは、自己効力感の欠如が原因であることがあります。一旦やる気を出すと案外簡単に進められたとか、真剣に取り組むと思ったより

    ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita
  • 真面目な人を本気にさせる方法

    先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「気(マジ)と真面目(マジメ)」の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。 気と真面目 人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして気になる。端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー(真面目)をしてしまうが、当に欲しかったことに対して考え始める(気)は実際のプロダクトを前にしてからという話だ

    真面目な人を本気にさせる方法
  • プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!

    今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ

    プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
  • すべての開発者が知っておくべき、ソフトウェアアーキテクチャに関する5つのこと

    Mark Fussell氏とYaron Schneider氏とDaprを知ろう 日のエピソードでは、Thomas Betts氏がMark Fussell氏とYaron Schneider氏に、分散アプリケーション・ランタイム(Dapr)について話を聞いた。最新のInfoQ Architecture and Design Trends Reportでは、Daprはポータビリティとクラウドアプリケーションのための設計というアーリーアダプターのアイデアの一部となっている。

    すべての開発者が知っておくべき、ソフトウェアアーキテクチャに関する5つのこと
  • 移動しました - SmartHR Tech Blog

    行政手続きの電子申請をもっと身近に!CSV 形式届書作成ライブラリ「kirico」を公開しました - SmartHR Tech Blog

    移動しました - SmartHR Tech Blog
  • Multisize Resizer | 画像を複数サイズに一括リサイズ

    指定サイズリストの設定は、ファイルに保存して再利用することができます。 設定サンプル1 サイズ1:サムネイル画像50×50(全体表示・白背景) サイズ2:詳細画像400以下×300以下(元画像の比率に合わせる・縦長横長維持) 設定サンプル2(Adobe Air Iconサイズ) サイズ1:16×16(全体表示・背景透過PNG) サイズ2:32×32(全体表示・背景透過PNG) サイズ3:48×48(全体表示・背景透過PNG) サイズ4:128×128(全体表示・背景透過PNG) ①画像が縦長の場合に縦横の指定サイズを入れ替える 横長画像の場合と縦長画像の場合で、縦横サイズ指定を入れ替えます。 横長画像・縦長画像が混在していて、横長・縦長をそれぞれ維持したい時に効果的です。 ②リサイズ後の画像ファイル名に文字を追加 リサイズ後のファイル名に指定した文字を追加します。 ③リサイズ画像を指定サイ

    Multisize Resizer | 画像を複数サイズに一括リサイズ
  • とりあえず触ってみる所から始める、『SHENZHEN I/O』 - Qiita

    実際にアセンブリを書く『SHENZHEN I/O』というパズルゲームがあります。 自分の回りでは非エンジニアのプレイヤーも日々増えていて、スコア画面が賑っていて大変嬉しいです。 Steam:SHENZHEN I/O しかし、プログラムに触れた経験が無い場合、ゲーム開始のとっかかりを得れなくて1問目に立ち向かう前に頓挫してしまう事もあるようです。 特に英語PDF 資料にまず目を通さねばならない点は非情に高い障壁である為、 「 pdf 資料とかいいからとりあえず最初の問題を触ってみよう!」という主旨で このような記事を執筆しています。 ※この記事は非エンジニアの方に向けたものなので、エンジニアの方には簡単すぎるかもしれません。 ※また 英語pdf にはストーリー部もあり面白いので、余裕が出たら一度読んでみる事もお勧めします。 まずは1問目 ゲームサイトのレビューにて 30ページ長のマニ

    とりあえず触ってみる所から始める、『SHENZHEN I/O』 - Qiita
  • 最近話題の『Arduino』とは一体何なの?何ができるの?まとめ | IDEA HACK

    誰が使うの? Arduinoは、アーティストやデザイナー、ホビイスト、そしてインタラクティブな物や環境を作りたいと考える、あらゆる人に向けて制作されたものです。 どこで買えるの? Arduinoは世界各国で販売されており、日でもAmazonやその他オンラインショップ、パーツショップ等で購入可能で、開発環境となるソフトウェアも無料でダウンロードできます(WindowsMac OS X、Linux対応)。 Arduinoについてもう少し詳しく Arduino単独で、スタンドアロン型のインタラクティブデバイス(単体で動くコンピュータ)を開発することもできますが、ホストコンピュータ上のソフトウェア(例えば、Adobe Flash、Processing、Max/MSP、Pure Data、SuperCollider等)で制御することもできるため、柔軟で使いやすい電子プロトタイピング・プラットフォ

  • ソフトウェアプロセス技術がロストテクノロジーになっている - きしだのHatena

    最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段

    ソフトウェアプロセス技術がロストテクノロジーになっている - きしだのHatena
    ombran
    ombran 2015/03/12
    基礎過ぎて話題にすらならないんだろうけど、その結果プロセスそのものを知らないって人が出てきてるんだろうな
  • そろそろ「テスト」という言葉を使うのをやめたほうがいいのかもしれない - assertInstanceOf('Engineer', $a_suenami)

    週末になごやのこわい人*1が東京に来てたのでいろいろ話したんだけど、そのときにちょろっと出た話について忘れないうちにまとめておく。 タイトルの件だけど、結局僕らはテストをやりたいというよりはいいプロダクトやいいサービスを作りたいのであって「テスト」という言葉を使っちゃうといろいろ誤解されることもあるなーと思った。 ソフトウェアの世界で「テスト」と言うといわゆる単体テストとか結合テストとかシステムテストとかのことを暗黙的に示してしまうわけで、それは仕様通りにソフトウェアが実装されているかどうかを確かめる行為であると認識されることが多い。実際にはさらにその先にそのソフトウェアがどの程度の価値を生み出したかという重要な指標があるんだけど、それは「マーケティング」と呼ばれたり最近だと「UXデザイン」と呼ばれたりしてソフトウェアテストとは別のものとして扱われたりする。 でも、機能上のバグだろうと、性

    そろそろ「テスト」という言葉を使うのをやめたほうがいいのかもしれない - assertInstanceOf('Engineer', $a_suenami)
  • 1