並び順

ブックマーク数

期間指定

  • から
  • まで

441 - 480 件 / 1764件

新着順 人気順

it業界の検索結果441 - 480 件 / 1764件

  • ソフトウェア設計についての原則や法則についてまとめてみた

    ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI(You ain't gonna need it.) YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の

      ソフトウェア設計についての原則や法則についてまとめてみた
    • 「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball

      界隈で話題になっている(と私は認識している)「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ! という現役エンジニア(私)による書籍の感想エントリーとなります. 話題の本めちゃ良かったです. このブログを書く数日前にkindleで買って読む→めちゃいいやん!→紙版も買う←今ここ ってぐらいすごく良かったです*1. 世界一流エンジニアの思考法 (文春e-book) 作者:牛尾 剛文藝春秋Amazon 何が良かったか一言で言うと, 「強いエンジニアの習慣がここまでいい感じに言語化されている!!!」 という所ですね, 割と余すところなく詰まっていると思いますし, 一つ一つのTipsは再現性もあると思います(真似できるかどうかは別として真似は可能*2). そんな「世界一流エンジニアの思考法」の感想を手短に書きます, 気になる方はお付き合いください. TL;D

        「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball
      • ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など

        ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 以下は選出された技術書部門とビジネス書部門それぞれのベスト10を、Amazon.co.jpへのリンクと画像、概要で紹介したものです(アフィリエイトリンクは含まれていません)。正式

          ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など
        • 【アプデ/10】 2019年8月14日のWindowsUpdate後、VB関連が死亡。Windows10全バージョンにて [Update 5: v1903がKB4512941にて修正。全バージョン修正完了] | ニッチなPCゲーマーの環境構築Z

          2019年8月14日に配信されたWindowsUpdateを適用すると、Windows10全バージョンにて、VBVisual Basic 6 (VB6)で作成したアプリケーション、Visual Basic for Applications (VBA)で作成したマクロ、Visual Basic Scripting Edition (VBScript)で作成したマクロやアプリケーションが応答しなくなり、『invalid procedure call error.』と表示される場合があるという不具合が発生していました。 2019年8月17日以降に配信された下記の『修正KB』(またはそれ以降のKB)を適用することでこの不具合は発生しなくなります。

            【アプデ/10】 2019年8月14日のWindowsUpdate後、VB関連が死亡。Windows10全バージョンにて [Update 5: v1903がKB4512941にて修正。全バージョン修正完了] | ニッチなPCゲーマーの環境構築Z
          • webブラウザのタブをたくさん開いたままにしてしまうのはブックマークの利便性が追い付いてないからでは?という話に集まるあるあるの声と便利情報

            画力・博士号・油田 @bd_gfngfn ユーザがタブを開きすぎる問題,端的な原因は「履歴とブックマークの利便性がタブを開き続ける場合のそれを超えることができていないから」に思える(少なくとも自分はそう) 2022-04-26 22:16:07

              webブラウザのタブをたくさん開いたままにしてしまうのはブックマークの利便性が追い付いてないからでは?という話に集まるあるあるの声と便利情報
            • MITからメルカリにやってきた20代AIエンジニアが放つ偉才っぷり「趣味でやってみたら天職でした」 - エンジニアtype | 転職type

              2019.08.22 働き方 AI等のテクノロジー で「売ることを空気に」することを目指すというテックカンパニー・メルカリ。同社では現在すでに国内外から集まった約40名のAIエンジニアが活躍しており、10月にはさらに約16名の新入社員を迎えるという。 そして今、メルカリの中でも特に偉才っぷりを発揮しているのが、AIエンジニアの松岡玲音(まつおかれいん)さん(27)だ。 株式会社メルカリ AIエンジニア 松岡玲音さん(@lain_m21) 1992年生まれ。東京大学薬学部卒業後、アメリカの大学院へ渡り宇宙工学を専攻。その後、機械学習のロボットへの応用へ興味を持ち、マサチューセッツ工科大学(MIT)の航空宇宙工学専攻へ転学。ロボットAIなどについて研究を重ねた後、中退。2018年10月よりメルカリでインターンシップをはじめ、2019年1月に入社し、現職 メルカリに入社するまで「Pythonは独

                MITからメルカリにやってきた20代AIエンジニアが放つ偉才っぷり「趣味でやってみたら天職でした」 - エンジニアtype | 転職type
              • リモートワークを3年強やって思うところを書き殴ったもの - memo_md

                諸事情により、近々リモートワークについて自分の私見を述べる機会が発生した。 考えるほどに「そもそも自分はリモートワークについてどう考えている(いた)んだっけ?」と深みにはまっているので、一度ここに全部吐き出してみることにする。 注意事項 すべて個人の意見であり、特定の個人・組織に関しての何らかの意図は一切無いです。また、脳内整理のために書き殴った文章なので色々アレですがご勘弁ください。 なぜリモートワーカーになったか 自社サービス開発をやってみたかったが、富山で思い描くような仕事は難しそうだった。かつ、家庭の都合もあり「単身都会へGO!!」とかは無理だった。 リモートワークという働き方は以前から知っていたので、 思い描くような仕事ができる リモートワークでも可 という考えで仕事を探した結果今に到る。やりたいことありきで、「リモートワークをしたかった」わけではない。 現在で3年強リモートワー

                  リモートワークを3年強やって思うところを書き殴ったもの - memo_md
                • 「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話 - Qiita

                  物語の始まり 事の発端は納品後。 先方からメッセージが届きました。 クライアント様「このファイルの文字コードがShift_JISになっておりますので、UTF-8で再納品をお願いいたします。」 拙者(あれ…UTF-8にしてたと思うんだけどな) 拙者「確認いたします。」 文字コードを確認する 本案件はいわゆる更新案件で、今回の納品時に言われていたのは、「文字コードがUTF-8ではないものは変換して納品してくれ」ということ。 そして、ご指摘いただいたのは、今回の更新案件で中身はいじらなかったJavaScriptファイル。 本来ならば納品するファイルではないのですが、文字コード変換という要件があったため、納品ファイルとして加えられたものでした。 一括で文字コードを変えたので作業漏れかなぁと思っていました。 ファイルの中身は記事用にかなり適当につくったものですが、まあだいたいこんな感じです。

                    「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話 - Qiita
                  • 育児中&共働きなので、効率よく「時短」できる家を建てた【エンジニア、家を建てる】 - MY HOME STORY │スーモカウンター注文住宅

                    職業柄、「よりよいもの」や「よりよい環境」を求める方が多いエンジニア。そんなエンジニアの「家づくり」にはきっと、さまざまなこだわりが詰め込まれているはず。 注文住宅を選んだエンジニアに登場いただく「エンジニア、家を建てる」。第1回はcorocn(土屋貴裕)さんに寄稿いただきました。 5年前から岐阜県でリモートワークを続けているcorocnさん。お子さんの誕生をきっかけに建てた家には、何かと忙しい共働き夫婦ならではの「時短」への工夫が施されています。 岐阜でソフトウェアエンジニアをしているcorocnと申します。 5年ほど前から地元の岐阜でリモートワークをはじめ、今は東京の Leaner Technologies というスタートアップ企業にフルリモート勤務しています。妻と2歳の息子の3人で暮らしており、子育てをきっかけに家を購入しました。 今回はエンジニアならではの観点も含め、フルリモートワ

                      育児中&共働きなので、効率よく「時短」できる家を建てた【エンジニア、家を建てる】 - MY HOME STORY │スーモカウンター注文住宅
                    • 準委任契約に基づく報酬請求と善管注意義務違反 東京地判令2.9.24(平28ワ28934) - IT・システム判例メモ

                      開発は途中で終わった場合でも、準委任契約に基づく報酬請求はできるが、適切な計画立案・実行ができていなかったとして善管注意義務違反が認められた事例。 事案の概要 イベント企画会社Yは、自社の企画するイベントを管理するためのシステム(本件システム)の開発をXに依頼することとした。 平成28年3月にXは開発に着手したが、その時点では契約書が取り交わされておらず、4月になって、X・Y間で以下の内容(抜粋)の契約書が取り交わされた(本件契約)。 1条2項 本件契約は,Xが(中略)業務に従事する技術者の労働をYに対し提供することを主な目的とし,民法上の準委任契約として締結されるものとする。したがってXは,善良なる管理者の注意義務をもって(中略)業務を実施する義務を負うものとし,原則として成果物の完成についての義務を負うものではないものとする。 3条3項 前各項にかかわらず,Yは,Xの本件サービスの業務

                        準委任契約に基づく報酬請求と善管注意義務違反 東京地判令2.9.24(平28ワ28934) - IT・システム判例メモ
                      • Twitter で医師が拾われて Google のソフトウェアエンジニアになって 3 年半が過ぎました - nodchipの日記

                        はじめに 『天才』はつくれる 競技プログラミング同好会競技就活部門 Google は世界最高のプログラミングスクールである 雇用形態と働き方 ソフトウェアエンジニア (SWE) Google でのお仕事 Google の面接の内容 Google の面接の問題の種類 コーディングクイズ 知識を吐き出す系 Open-ended question システムデザイン Google の面接の評価基準と対策方法 知識 技能 マインドセット Google の面接のタブー Google の面接の心構え 面接官への話し方 話す量 エリート意識 自己愛 優秀さ、知識量に対するこだわり Google の面接のテクニック 入力条件を確認する 入力の条件を簡単にできるか交渉する テストケースを作って提示する 関連する知識を答える 正しく修正する 競技プログラミングと Google の面接 おわりに はじめに nuc

                          Twitter で医師が拾われて Google のソフトウェアエンジニアになって 3 年半が過ぎました - nodchipの日記
                        • 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り - ヴェルク - IT起業の記録

                          2022年4月11日にboardの有料登録社数が4000社を突破したので振り返りです。 boardの正式リリースは2014年8月20日なので、約7年半ほどで、推移はこんな感じでした。 1000社刻みで定点観測的に書いているので、過去の記事も貼っておきます。 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス(BPStudy発表時の補足) 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入3000社に行くまでの振り返り boardとは 見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の小規模な会社をメインターゲットとしています。 8年目にして初めてサービス紹介動画を作ったので貼っておきます。

                            受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り - ヴェルク - IT起業の記録
                          • Colorbase

                            All-in-one color tool for creators

                              Colorbase
                            • エンジニアの技術土台となる知識を得るための本の紹介 - Qiita

                              はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え

                                エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
                              • 『タクティクスオウガ』のマップはなぜ、圧倒的なクオリティと規格外のボリュームを両立できたのか? その裏には業界最古のゲームエンジン「HERMIT」の存在があった

                                『タクティクスオウガ』。その名を耳にして思い浮かぶのは、発売から25年以上の年月が経った今もなお、圧倒的な支持と人気を得ているという、スーパーファミコン後期の名作タクティカルRPGとしての確固たる姿だろう。 © 1995 SQUARE ENIX CO., LTD. All Rights Reserved.(画像は『タクティクスオウガ』公式サイトより) そんな『タクティクスオウガ』の開発には「HERMIT」(ハーミット)なるものが用いられていたことはご存じだろうか。 「HERMIT」とは、『タクティクスオウガ』を販売・開発した株式会社クエストが独自に作り上げた開発ツール……今で言う「ゲームエンジン」に相当する存在だ。この謎のゲームエンジンが、実は『タクティクスオウガ』の開発にあたって大活躍をしていたという。 ではこの「HERMIT」は、いったい何がすごかったのか? まずひとつ目のポイントは、

                                  『タクティクスオウガ』のマップはなぜ、圧倒的なクオリティと規格外のボリュームを両立できたのか? その裏には業界最古のゲームエンジン「HERMIT」の存在があった
                                • アメリカで無職になった|Kazuki Tsutsumi

                                  ここ二ヶ月ほどアメリカで無職をやっている。結果から言うと無事転職先が決まったため既に先が見えた無職生活であるが、Temporary Worker Visa で働く人間が突如職を失うととどうなるかという貴重な経験だったため備忘録を残す。 無職以前San Francisco の Fintech Startup で Sr. Software Engineer として働いていた。前々職でもシリコンバレーで日系企業の駐在員として働いており、帰任と同時にオファーを貰って転職した。会社は H-1B ビザの申請をサポートしてくれて抽選にも通ったが、コロナ禍により大使館面接が停止し、結局一年以上日本からリモートで働いた後、2020 年末にやっと渡米することが出来た。 会社の特徴としては全面的に Clojure を使って開発をしていた。元々 Clojure Developer であった自分が採用された理由であ

                                    アメリカで無職になった|Kazuki Tsutsumi
                                  • ITエンジニア本大賞2020

                                    特別ゲスト プレゼン大会に審査員として参加いただく特別ゲストの紹介です。おすすめ本を3冊、ご紹介いただいています。 永瀬美穂(ながせみほ)さん アジャイルコーチ。株式会社アトラクタFounder兼CBO。一般社団法人スクラムギャザリング東京実行委員会理事。認定スクラムプロフェッショナル。産業技術大学院大学特任准教授、東京工業大学および筑波大学非常勤講師。著書に『SCRUM BOOT CAMP THE BOOK』訳書に『レガシーコードからの脱却』『アジャイルコーチング』『ジョイ・インク 役職も部署もない全員主役のマネジメント』。 アジャイルイントロダクション 大御所バートランドメイヤー氏によるアジャイルへの批評。仕事柄アジャイルに懐疑的な人に出会うことがあるが、ここまで冷静な批判は聞かないので読み応えがあり、耳も痛い。ソフトウェア工学的見地から、再現不能な事例や理想論、ご都合主義に文句をつけ

                                      ITエンジニア本大賞2020
                                    • Adobe製品を使わない"デザイナー"?「ビジュアルコーダー」が考える、自己満足で終わらないWebデザインとは

                                      Adobe製品を使わない"デザイナー"?「ビジュアルコーダー」が考える、自己満足で終わらないWebデザインとは

                                        Adobe製品を使わない"デザイナー"?「ビジュアルコーダー」が考える、自己満足で終わらないWebデザインとは
                                      • SIerに生息する「おじさんSE」の生態を知る - Qiita

                                        ここでいうおじさんSEとは、主にSIerに生息する、 ・30歳以上で ・モダンな技術を知らない ・レガシーな技術しか知らない ・主に設計書などのドキュメント類を弄っており、コーディングをしない ・現状から変わる気がない(キャリアアップに対し具体的なアクションがない) 人たちを指す。 決して単に妙齢のエンジニアを一括りにしているわけではない。 「おじさんSE」より良い呼び方があれば、ぜひご提案いただきたい。 第1章 おじさんSEの仕事内容 おじさんSEは、コードを書くことはほぼ無い。 これは現場にもよるので、全く無いというわけではないが、 多くのおじさんSEはコーディングはしない。 ではおじさんSEは何をやっているのかというと、 ・内部設計書、外部設計書、詳細設計書の記述 ・結合試験以降の試験項目票の作成 ・試験結果のレビュー 大抵はこの3つになる。 99.9%はウォーターフォール型である。

                                          SIerに生息する「おじさんSE」の生態を知る - Qiita
                                        • 何が事業貢献なのか分からなくなっていた伊藤直也さんが再認識したユーザーエクスペリエンスへのコミット - Findy Engineer Lab

                                          ソフトウェアエンジニアは、どのように事業に貢献すべきか? 宿泊施設やレストランの予約サービスを提供する株式会社一休で執行役員CTOを務める伊藤直也さんは、2016年に入社しておよそ2年間、心の奥に抱えた悩みを解消できないまま仕事をしてきました。 伊藤さんは、2000年代から複数のWeb系テックカンパニーで技術部門のリーダーとして活躍し、現在でも利用される個人向けWebサービスのローンチをいくつか手掛けています。一休には入社以前からフリーランスで技術顧問を務めており、会社がヤフーグループ(当時)に入って経営陣が一新されるタイミングで、代表取締役CEOとなった榊淳さんの要請を受けて入社しました。 当時は全て.NETだったというサービス基盤の刷新や技術的負債の解消、開発組織の整備といったエンジニアリングにおいて重要な改善を進めてきましたが、あるとき自身が「事業に貢献していない」ことを明確に意識す

                                            何が事業貢献なのか分からなくなっていた伊藤直也さんが再認識したユーザーエクスペリエンスへのコミット - Findy Engineer Lab
                                          • みずほ ATM予定どおり稼働再開 システム刷新作業終える | NHKニュース

                                            「みずほフィナンシャルグループ」が去年から進めてきた銀行の中枢のシステムを刷新する作業がすべて完了しました。この連休中に止めていた全国のATM=現金自動預け払い機は、16日朝サービスを再開し、トラブルなく稼働しています。 作業は16日朝、すべて完了し、ATMやインターネットバンキングは今のところトラブルなく稼働しているということです。 窓口での振り込みの手続きなども通常どおり行われています。 また、IT各社が提供しているキャッシュレス決済サービスへのチャージも問題なく利用できているということです。 みずほは2002年と2011年に大規模なシステム障害を起こした反省から、今回のシステムの刷新ではトラブルを防ぐため作業を9回に分けて慎重に進めてきました。 総額4000億円をかけ、みずほ発足以来、最大の懸案となってきたシステムの刷新がようやく完了しますが、今後、最先端の金融技術、フィンテックを活

                                              みずほ ATM予定どおり稼働再開 システム刷新作業終える | NHKニュース
                                            • なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか? - Qiita

                                              はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム

                                                なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか? - Qiita
                                              • 大企業の最前線でコードを書き続けるためにやってきたこと

                                                https://talent.supporterz.jp/geeksai/2020/

                                                  大企業の最前線でコードを書き続けるためにやってきたこと
                                                • フロントエンドエンジニア御用達の MDN web docs を網羅した

                                                  このリストは何? MDN web docs を、あたかも書籍の目次かのごとく整理しなおしたものです。それぞれ MDN web docs の記事へリンクしています。 なぜこれが必要になったかというと、人材市場でフロントエンドエンジニアが少なすぎる現状をどうにかするべく教育体制を整えるところから考え始めたのですが、それならまずは日頃お世話になっている MDN web docs を教材として扱いたいなと思ったからです。慣れてきてもよく参照するし「アレどこだっけなぁ?」を軽減もしやすいかなって。 MDN web docs は内容そのものはかなり充実しているものの、リンクがあらゆる方向に張り巡らせられており ある一定の流れに沿って読む ということが少々難しい側面もあります。特に初学者にとっては、迷子になりやすいかもしれません。 ですので、初学者でも学習しやすいように MDN web docs 全体の

                                                    フロントエンドエンジニア御用達の MDN web docs を網羅した
                                                  • エンジニア妻がスクラムを家庭にざっくり導入したら仕事よりうまくいった話 | ママニュー

                                                    私はIT企業に勤める、フルタイムのワーキングマザーです。食品メーカーで営業職を務める夫と小学校2年生、保育園年中の息子の4人家族で毎日バタバタと過ごしています。 普段は自社サービスのシステム開発を担当しています。超忙しい部署ですが、最近、チームのコミュニケーションルールにちょっとした変化があって、以前よりももっと仕事が楽しくなったんです。 そのいい流れを家庭にも取り入れてみたら、さらに良い家族になれたので、まとめて書いてみようと思います。 開発チームが良い方向に変わった 私が所属する開発チームでは、これまでは完全分業制で開発を進めていたのですが、コミュニケーションを重視した「スクラム開発」という手法を取り入れるようになりました。 チームとして成果をあげ、チームでプロジェクトを進めるための仕組みです。全員がプロジェクトの現状とタスクを把握しながら、協力しあって開発を進めていきます。 それから

                                                      エンジニア妻がスクラムを家庭にざっくり導入したら仕事よりうまくいった話 | ママニュー
                                                    • シリコンバレーで働いてる俺が今回のTwitter買収について私見を述べる

                                                      ここのところ毎日ニュースになっている、イーロンマスクのTwitter買収とその後の施策について、シリコンバレーでソフトウェアエンジニアをしている俺が、Q&Aの形で私見を述べる。 Q. Twitterは倒産寸前だったんだからレイオフは当たり前では?これは間違い。確かにTwitterは慢性赤字企業だったが、倒産寸前だったことは一度もない。しかし今回マスクがLBOを使ってTwitterを買収したため、Twitterにかかる借金が大量に増えた。金利だけで、次の7−8年に90億ドルもの支払いが発生するらしい。 https://www.wsj.com/articles/how-elon-musks-twitter-faces-mountain-of-debt-falling-revenue-and-surging-costs-11669042132 さらに言えば、マスクはTwitterを多分時価2倍以

                                                        シリコンバレーで働いてる俺が今回のTwitter買収について私見を述べる
                                                      • 無職に飽きたので人工衛星のソフトウェアをRustで作っています - Write and Run

                                                        KOBA789 です。 今年2月末に前職を退職してからここ半年ほど無職をしていたのですが、いよいよもって無職に飽きてきたので人工衛星を作ることにしました。 実は9月頭から働いています。 株式会社アークエッジ・スペース 次の職場は株式会社アークエッジ・スペースです。東大の研究室発のスタートアップで、衛星バス開発を得意としている会社です。 衛星バスというのは、言ってしまえば人工衛星の OS に相当するものです。 OS に喩えましたが、もちろんそれは単なるソフトウェアではなく物理的な実体を伴うハードウェアとその中で動作するソフトウェアの集合体です。 ちなみにユーザーランドに相当する部分はミッション機器と呼ばれます。 まだまだ人数の少ない会社ですが、業界の土地勘や人脈に富んだ CEO や、人工衛星開発の経験があるエンジニアが揃っており、スタートアップとしては超実力派です。 ArkEdge Spac

                                                          無職に飽きたので人工衛星のソフトウェアをRustで作っています - Write and Run
                                                        • 日立に戻りたいわけがない。 - テストステ論

                                                          新卒で日立へおれが新卒で入ったのは、日立製作所だ。 おれが面接を受けたのはシステム開発研究所というところだったが、 おれが入った年に研究所の再編成があって、横浜研究所というところに配属になった。 横浜研究所は横浜の戸塚というところにあり、 寮はそこまでバスで一本のところにあった。 寮生活は隣人の先輩が発狂して泣き叫びだしたり、色々トラブルはあったが、 まぁ楽しかった。 寮というのはなかなかいいものだ。 京大で吉田寮や熊野寮にわざわざ住みたいという人がいることも微妙にだが理解出来る。 システム開発という名前のとおり、 そこはソフトウェアの応用研究をやってる研究所で、 と言っても企業の応用研究というのは事業所から依頼された研究(通称、依頼研)だったり、 あるいはもう少し先のことを考えた先行研と呼ばれるものがあったするくらいで、 大学のような研究をやってるというところではないのだが、 まぁおれ的

                                                          • 現役高校生が、AtCoderでレッドコーダーになるまでにやってきたこと。プログラミング上達の秘訣を全て教えます - Findy Engineer Lab

                                                            こんにちは、はじめまして。筑波大学附属駒場高等学校 3 年生(今年 4 月から東京大学に入学予定)の米田優峻(@e869120)と申します。私は競技プログラミング(競プロ)が趣味で、AtCoder・情報オリンピック・パソコン甲子園などの大会に出場しています。2021 年 3 月時点で、AtCoder では赤色(レッドコーダー)です。また、国際情報オリンピックの 2018 年/2019 年/2020 年大会で金メダルを獲得しています。*1 とはいえ、決して簡単にこの記録を手に入れられたわけではありません。何度も挫折と失敗を経験しながら自分のスキルを磨いた結果、競プロを始めてから 3 年後にはレッドコーダーになることができたのです。 今回は「わたしの選択」というテーマで寄稿の機会を頂いたので、私が中学 1 年生の秋に競技プログラミングを始めてからレッドコーダーになるまで、そして国際情報オリンピ

                                                              現役高校生が、AtCoderでレッドコーダーになるまでにやってきたこと。プログラミング上達の秘訣を全て教えます - Findy Engineer Lab
                                                            • [いわゆる退職エントリ] Microsoft を辞めることにしました(あるいはサポートエンジニア → Product Marketing Manager になるまでなど) - Qiita

                                                              [いわゆる退職エントリ] Microsoft を辞めることにしました(あるいはサポートエンジニア → Product Marketing Manager になるまでなど)退職エントリ 皆さんごきげんよう。ういこうと申します。 これまで日本マイクロソフト株式会社で Azure のフロントエンド領域を中心としたサービスの Product Marketing Manager をしておりましたが、6/30 日をもって退職することとなりました。 きっと Microsoft 界隈以外では、あなたどなた?という感じだと思いますので、少し自己紹介と、退職エントリ(のようなもの)を書くことにした理由を紹介させてください。ちょっと、いや...かな~り長いので、おやつでも食べながら読むものがないなーというときや、今エンジニアなんだけど、マーケティングなど、テクニカル ロール外の職種に転換しようと思ってる、あるい

                                                                [いわゆる退職エントリ] Microsoft を辞めることにしました(あるいはサポートエンジニア → Product Marketing Manager になるまでなど) - Qiita
                                                              • (年収270万で)プログラマーを引退して、医学部にきた俺が真面目に考えて..

                                                                (年収270万で)プログラマーを引退して、医学部にきた俺が真面目に考えてやろう。 ① 言葉は正しく使おう真面目に読んでいて、ちょっと気になる箇所がある。たとえば PostgreSQL を postgre とか書くヤツは現場では嫌われるぞ。少なくとも postgres と書いてくれ。お里が知れるぞ。 ② プライドが高い消えていくエンジニアの特徴だけど、叱責されたり馬鹿にされるのが嫌で VCS にコミットしないヤツ、または貪欲にコードレビューをされるのが嫌がるやつは、成長しない。 ③ エリート意識この業界は数年前には『デジタル土方』と揶揄される業界でした。ちなみに、アメリカでも「テック系はハードだから避ける」という雰囲気でした。つまり何をいいたいのかというと、ソフトウェアの開発者っていうのは「泥臭い領域」なんだよ。エリートとは程遠い場所にあるというね。 ④ 「某天市場の先輩には,ここ仕事量少な

                                                                  (年収270万で)プログラマーを引退して、医学部にきた俺が真面目に考えて..
                                                                • マンガではわからない ソフトウェア開発の真理 | ドクセル

                                                                  目指せ脱UE4初心者!?知ってると開発が楽になる便利機能を紹介 - DataAsset, Subsystem, GameplayAbility編 -

                                                                    マンガではわからない ソフトウェア開発の真理 | ドクセル
                                                                  • オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling

                                                                    Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui

                                                                      オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
                                                                    • 富士通SEの退職理由が壮絶…メモリ4GBのPCで開発、ひたすら進捗会議

                                                                      富士通の本社移転先となる同社川崎工場(「Wikipedia」より) 大手IT企業の富士通で以前働いていた元システムエンジニア(SE)が「退職した理由」を綴ったインターネット上の投稿が、一部で話題を呼んでいる。そこには、開発環境の古さや、無気力な人材や組織体制の問題、給与面を含めた待遇の悪さなどが書かれている。「5年いた富士通を退職した理由」というタイトルの投稿は、「5年間エンジニアとして務めた富士通を一昨年退職した」「自分の半径5m以内で起こった幼稚な理由にフォーカスを当てる」と始まり、「開発環境がだめ」という項目では 「メモリ4GBのセレロン使ってた。もちろんSSDじゃなくてHDD。PCは富士通製のミドルクラスのノートPCしか支給されなかった。Macなんか認めん!iOSアプリも富士通PCで作れ!(本当にあった話)」 と、貧弱な開発環境を嘆いている。自身もIT企業でSEとして働いた経験があ

                                                                        富士通SEの退職理由が壮絶…メモリ4GBのPCで開発、ひたすら進捗会議
                                                                      • プログラマーがドキュメントを書かない理由

                                                                        この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである

                                                                          プログラマーがドキュメントを書かない理由
                                                                        • やっぱITは内製が進むと思う

                                                                          SESや多重下請け構造だと、基本的にスキルというよりは単純労働力が求められる。 人を増やして、時間工数を水増ししたほうが儲かるからである。 新しい技術を使って100時間で開発するより、Excel作業で2000時間かけたほうが20倍もうかる。 ここに商売としての邪悪なトリックがある。 よって、多重中抜きの元請けには、IT技術というより「人売り」「奴隷商人」のスキルが求められる。 その結果、本当にIT以前のレベルの人間もちらほらいる。 異業種のトップ人材のほうが確実にITツールを使いこなしていると感じるレベル。 「それで肩書がエンジニアなの?」という失望感から怒りに変わることも多いので、 根っからのエンジニア気質の人間は、内製の会社に行った方がいい。技術で社会貢献できるだろう。 あと人売りのポンコツの多くは、あまり自分のレベルアップに興味がなく、 会社にしがみついて人生を平凡に逃げ切るプランを

                                                                            やっぱITは内製が進むと思う
                                                                          • プログラマーのための原則(2 万字) - Qiita

                                                                            はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』(1999 年)で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同

                                                                              プログラマーのための原則(2 万字) - Qiita
                                                                            • 三流プログラマがなぜ米マイクロソフトの開発者になれたのか? ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Regional Scrum Gathering Tokyo 2022

                                                                              三流プログラマがなぜ米マイクロソフトの開発者になれたのか? ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 子供の頃からプログラマになることを目指しながらも、同僚からは「プログラミングの才能がない」とはっきり言われるなど、自分はガチの三流プログラマだと称する

                                                                                三流プログラマがなぜ米マイクロソフトの開発者になれたのか? ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Regional Scrum Gathering Tokyo 2022
                                                                              • VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)|Takayuki Shimizu

                                                                                (この記事はVPoE handbookの目次&サマリパートです) 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 (この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。) VPoE handbookを書こうと思った理由まずはなぜ書こうと思った?の問題意識から。 この記事にあるように、三

                                                                                  VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)|Takayuki Shimizu
                                                                                • 要件定義、基本設計、詳細設計の流れを総復習

                                                                                  はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ?」 「基本設計との違いって何だったっけ?」 「基本設計と詳細設計の区別って?」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて1からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部(特に要件定義や基本設計、詳細設計のサンプル)を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく

                                                                                    要件定義、基本設計、詳細設計の流れを総復習