コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
成長の早いジュニア・ソフトウェアエンジニアの特徴 - /june29 は /juneboku に移行しました
こちらが伝えた内容から不要なことを邪推しないというか、文字通りに「真っ直ぐ」である人は、望ましい行動に最短経路で向かっていくので効率的な行動を選択していくな、と感じます。「なにかわからないことがあったら、すぐに質問してくださいね」と言われたときに、実際にすぐに質問できる人はどんどん前に進んでいきます。余計なことを考えない分、リソース効率がよいのでしょう。 ぼく個人は、人間はもともと素直な生き物なんじゃないかと思っています。それが、イヤな体験を重ねるたびに少しずつ防衛的になって、だんだんと素直さに蓋をしてしまうケースがあるイメージです。「それくらい自分で調べろ、いちいち質問するな」と怒鳴られるようなことがあったら「すぐに質問してね」と言われてもなかなか実行に移せなくなりそうですよね。そういう人は「自分は、そういう状況である」というのを自覚することから始めるとよいでしょう。「質問してよかった」
ソフトウェア1 (2020)
ソフトウェア1 (2020)¶ 本サイトは、東京大学工学部電子情報工学科・電気電子工学科の進学内定者（２年生、A1ターム）を主たる対象としたソフトウェア１の講義ページです。C言語の基礎を勉強します。 電気系の学科のslackにて講義に関する通知を行うので、常時学科slackをチェックするようにしてください。 電気系の2年生は最初のオリエンテーションで全員slackに招待されるはずですが、もし招待されていなければ松井まで連絡してください。 3年生は既に全員招待済みのはずです。電気系以外の履修者、および4年生は招待されていないので、松井まで個別に連絡してください。 本サイトは2020年度版です。2021年度版はこちら。 ニュース¶ [2020.11.16] Q&Aにweek7を追加しました。 [2020.11.12] week7、およびバージョン管理を追加しました。 [2020.11.09]
ほとんど理解されていない「良い戦略、悪い戦略」 – suadd blog
「戦略」とは何か、を深く考えさせられる良書。経営思想家として大学やコンサルタントとして活躍しているリチャード・Ｐ・ルメルトが、様々な事例をもとに良い戦略の作り方を書いています。事例は後付けの生存者バイアスがかかっているものの、多くは納得感がありました。また、そこまで体系だっているわけでもないですが、実例が大変おもしろく、非常に勉強になりました。 自社を振り返ると、無意識にうまく戦略を実行してきたこともありましたが、全然できてないなぁと思うことも多く、どうやったら良い戦略を作り、実行していけるかをすごく考えさせられました。すぐに役に立つことも多かったですし、まさに今、中期経営計画を更新しているところでもあり、活かしていきたいと思ってます。 良い戦略がなければ、まぐれ当たり以外、成功するのは難しいので、特にスタートアップに関わるひとには必読かなと思います。 以下、ちょっと長くなってしまいました
ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える
ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により
「経験の浅いソフトウェア開発者が気になっていること」という募集への反応のまとめ - 覚書
数日前にブログや記事、書籍執筆ネタ集めのためにこういうtweetをしました。 [ゆるぽ] 経験の浅いソフトウェア開発者が気になっていること、とくにすでにそれなりのキャリアを積んだ人に聞きたいこと もっというと別に(ソフトウェア技術者としての)私個人について聞きたいことでもいいです— sat🧊 (@satoru_takeuchi) 2020年2月28日 その結果、返信および引用RTで数十個のネタが寄せられたので、まとめてみました。その場で回答したものについては回答一緒に書いています。それに加えて、私がわからないと言ったことについて別のかたから回答をしていただいたものについても書きました。さらに、既に経験豊富なかたがたから「経験の浅いソフトウェア開発者が気になっていそうなこと」や「知っておいてほしいこと」のようなネタもいただいたので、こちらもまとめました。 文面は基本的には改変せずにそのまま
コードを書いて金を稼ぐ - kuenishi's blog
初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社（割と稼いでいる）で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。なお収入なので税金の扱いを間違えないように。しかし特許といえばガッポガポ…というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズ
ソフトウェアエンジニア社長として起業してから会社清算するまでの4年間の振り返り （前編）｜Takahiro Ikeuchi
こんにちは。池内です。これから綴るのは廃業エントリです。開幕から退職エントリとの格の違いを見せつけていくストロングスタイルでお届けしております（違）。 軽口はさておき、いまからおもむろに note を書き始めるわけですが、一番最初の note はこの話題でなくてはいけないだろうという清算の気持ちで文章を綴っています。会社清算だけに。 ・・・ Facebook で僕の投稿に反応いただいていた方はすでにご存じのとおり、そして Twitter や OSS関連コミュニティなどでのみ緩くつながっている方はもしかすると初耳になるかも知れません。じつは、とかしこまることもないのですが、2019年5月末をもって自ら設立した法人を解散するという意志決定をしていました。2015年8月の法人登記からおよそ4年という月日を、代表取締役というロールで過ごしました。この note はその体験をつうじて得た学びや気づき
ソフトウェアアーキテクチャの歴史 - tasuwo's notes
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法 - メソッド屋のブログ
アメリカに移住してもうすぐ４ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。 最初の２ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ４ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう？焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。 仕事が完了しない焦り 何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみ
ソフトウェアと
2013: はじめに 約5年前にソフトウェアエンジニアになりたくて前の会社を辞めた。当時3人の会社の4人目として入社。Web系のソフトウェアエンジニアの親しい友人はいない。その時からソフトウェアエンジニアコミュニティというものが存在していることは知ってたんだけど、どうしても好きになれくてその中に積極的に入っていこうという思いもあまりない。いわゆるスタートアップと呼ばれる会社だったけど、当時スタートアップ野郎には全く良い印象がなく、身内ノリがキモすぎてあまり関わりたくなかったので距離を取っていた。 会社で一日中設計してコードを書いて家に帰ってDjangoやfluent-agent-hydraやpaho-mqtt、気になったソフトウェアを写経して土日は自分が感じる不便を解決するOSSを書く。写経は脳を大きく動かさなくてもとにかく開始できるという一点において便利な練習で、その頃はよくやっていた。
業務知識を持たないリーダーで大丈夫か？ - kawaguti’s diary
2017年1月に米Microsoftに遊びにいって感じたことを、そのあといろんな人に伝えてきたのですけど、ブログには書いていなかった気がしますので、年頭にあたり書いておきます。 機動警察パトレイバー アーリーデイズ | Netflix (ネットフリックス) ツアーの際に現地で講演してくれた方の1人が河野さんで、ありがたいことに翌年のRSGTで基調講演していただきました。(もう1人Chap AlexはDevIpsDaysでお呼びできました。) 米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part1 - ログミーTech ここで痛感したのは、ビジネスに必要な業務知識を経営層・マネジメント層が持っていないと、もう儲からないんじゃないか？ということです。ソフトウェアに関する業務知識というと、コンピュータサイエンスだったり、もうちょっと基本的なレベルで、
世界基準を作った男。「CrystalDisk」シリーズの生みの親“ひよひよ氏”直撃インタビュー - エルミタージュ秋葉原
インタビュー Vol.37 世界基準を作った男。「CrystalDisk」シリーズの生みの親“ひよひよ氏”直撃インタビュー 2019.01.01 更新 文：エルミタージュ秋葉原編集部 池西 樹/Tawashi 自作派なら誰もが使うであろう「Crystal Dew World」のストレージ系ソフトウェア「CrystalDiskInfo」「CrystalDiskMark」。編集部は今回、その生みの親であるひよひよ氏にインタビューする機会を得た。国内のみならず、世界中のユーザーから支持を受けるソフトウェアは、どのようにして生まれたのだろうか。早速お話を聞いてみよう。 業界標準の国産ソフトウェアが誕生したきっかけ 編集部 出身は北海道ということですが、今は東京在住と聞いています。 ひよひよ氏 生まれも育ちも北海道です。ただし、現在は単身赴任中で、家族を札幌に残したまま東京の本社に勤務しています。
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明
技術的負債の「会計的」性質 – Ryohei Tsuda – Medium
負債とはなにかについてわたしたちが理解していないという事実そのもの、あるいはこの概念の融通無碍であることそれ自体が、負債の力の基盤である。 デヴィッド・グレーバー 「負債論」 ソフトウェア開発において、欠陥のある未熟な実装によって機能の追加や修正が難しくなることを、借金に喩えて「技術的負債」と呼ぶことがある（Wikipedia）。 現代のソフトウェアはもはや「サービス」に近い製品が多いが、サービスは顧客に受け入れられて初めて収益を生み出すことができる。広く使われているソフトウェアも最初は数少ない機能にたくさんのバグを添えてリリースされ、試行錯誤を経て顧客に受け入れられる。つまり、機能の追加や修正が難しくなることは、それ自体が潜在的な損失と言える。 しかし、私にはこの「技術的負債」という言葉は会計上の「借金」とは随分と異なる意味を持っているようにも思える。というのも極端な話、もし機能の追加や
最近のソフトウェア工学に思うこと - bonotakeの日記
なんかこのブログに記事書くの、ほんと久々だなと思うんですが。 最近ずっと思ってたことがあったので、つい勢いで書きなぐってしまいました。若干炎上商法かもしれませんが、まぁたまには？いいや。 長文ですがお付き合いください。特に、ソフトウェア工学の研究している皆さん。 昨日、とあるソフトウェア工学のシンポジウムにて、機械学習モデルをWebサービスにデプロイするためのハンズオン、という企画がありました。 僕が運営委員やってるMLSEとの共同企画で、僕は発案者の１人ですが、当日は1人の参加者として中に混じっていました。 4人グループに分かれての作業だったんですけども、僕以外の3人は、いずれもソフトウェア工学の研究をしている修士の学生さんでした。 で、ハンズオンも後半になって「Dockerの使い方」の演習になったのですが、その3人ともDockerに触ったことがなさそうな雰囲気でした。いちいち確認したわ
低レイヤーの学び方 ── システムソフトウェアの世界は「今すぐ役に立つものが全て」ではない - GeekOutコラム
はじめまして、木村 廉と申します。現在神戸大学大学院の修士2年生で、システムソフトウェアの脆弱性検出やself protectionについて研究しています。 § 実はこのコラム執筆のお誘いをいただいた時、はじめはお受けするかどうか少し迷いました。というのも、「GeekOut」の過去のコラムを見ると、執筆者の皆さんは最前線で活躍されている方ばかりで、一介の学生の私では見劣りするような気がしたからです。 しかしながら、私もエンジニアの端くれですので、他のエンジニアと差別化できる強みも多少は持っています。そしてそれは、幸いにも他の人とかぶりづらいマニアックな部類のもので、参考にできる資料も多くありません。 その強みとは、OSやハイパーバイザ（コンピュータを仮想化するための制御ソフトウェア）といった、基本的な制御を行うシステムソフトウェアを開発したり、それに手を入れたりすることです。いわゆる“低レ
Ideinの技術や事業の紹介
Ideinの中村です。弊社は4/7でちょうど設立3年目を迎えたベンチャー企業です。この記事では主に弊社の取り組む課題や事業などについて紹介したいと思います。主にエンジニアや研究者の方々向けに弊社が何をやっているのか知ってもらう事を目的として書いています。 社名・ロゴ社名のIdeinはイデインと読みます。アイデア(Idea)の語源になったと言われているギリシアの言葉で見る・知るという意味があります。画像認識技術をやっていく気持ちを表しています。ロゴは八咫烏です。 課題IdeinはDeep Neural Network(DNN)による画像認識等の推論技術を、ハードウェア製品に搭載する技術に取り組んでいます。クラウドやサーバーではなく末端のデバイス上でDNNモデルによる推論を実行するニーズが近年高まっています。 最近はEdge ComputingとかOn Device Inference等と呼ば
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
20年後のソフトウェアテストの話をしよう / Software Testing for 20 years later
