個人開発で売上を立てるための“ニッチ戦略” 「エンジニアである」強みを活かして、確度の高い成功を
個人開発者・なる氏は、非エンジニアの経営者に聞いた、エンジニアであることのメリットと、エンジニア事業者の落とし穴、個人開発で売上を立てるための戦略について話しました。 なる氏の自己紹介 なる氏（以下、なる）：先に言わせていただきます。僕のLTはちょっと情報量が多くなっているので、QRコードとかをけっこう出しています。なのでQRコードが出てきたタイミングで、気になったら適宜読み取ってもらえるとうれしいです。 （参加者の）みなさんはたぶんエンジニアが大半かなと思っているので、お待ちかねの、エンジニアがずっと褒められる、そんな時間の開始になります。というわけで、「エンジニアがどれだけ有利か」。「なる」と申します。 （スライドを示して）目次はこのようなかたちです。 自己紹介をすると……。「X」（の情報）を置いています。フリーランスになって4年目で、特化領域として、テックのスタートアップさんをクライ
伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】
TOPコラムキャリアを創る思考法伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】 伊藤淳一 1977年生まれ、大阪府豊中市出身。株式会社ソニックガーデンのRailsプログラマ、およびプログラミングスクール「フィヨルドブートキャンプ」のメンター。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に「プロを目指す人のためのRuby入門 改訂2版 言語仕様からテスト駆動開発・デバッグ技法まで」（技術評論社）などがある。 前回では、筆者がプログラマとして入社したSIer時代のエピソードと、そのあとに入社した外資系企業での社内プログラマとしてのエピソードを書いてみました。IT業界に入って間もないエンジニアさんや、これからの自分のキャリアを考え始めたエンジニアさんに
テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携
test.each([ {a: 1, b: 1, expected: 2}, {a: 30, b: 5, expected: 25}, ])('.sum($a, $b)', ({ a, b, expected }) => { expect(sub(a, b).toBe(expected); }); テーブル駆動テストは Go 言語を使った開発で良く使われるスタイルです。Go 言語の GitHub リポジトリの Wiki にはテーブル駆動テストに関するページがあるので、興味がある人はそちらを読んでみてください。 テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携 テストがなくリファクタリングが困難なフロントエンド 症状検索エンジン ユビー には、ユビーのビジネスにとって重要な、とあるページがあります。そのページではフロントエンドからロギングサービスに対してたくさんのロ
なぜ学習することへ投資するのか - エス・エム・エス エンジニア テックブログ
技術責任者の@sunaotです。エス・エム・エスのプロダクト組織では、カンファレンス参加や専門書籍による学習などを強く推奨して、金銭的・時間的な支援も広く行なっています。 取組み自体はとくに最近の Web の会社では珍しいものではありません。ただ、位置付けや考え方を表明しているのはやや珍しいらしく、入社してきた人やカジュアル面談の場などで説明すると面白がってもらえることがあります。そこで、今回はその背景や考え方を説明してみます。便宜上ソフトウェアエンジニアを例に説明をしますが、基本的にはプロダクトマネージャーやデザイナーなど他の職種においても同じことが言えると考えています。 学習への投資は責任を果たしてもらうための必要経費 エス・エム・エスのプロダクト組織では、カンファレンス参加や書籍の購入といったものに会社のお金や業務時間が使えることを福利厚生として位置付けていません。では、報酬ではない
日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ
今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル
プログラマのための公開鍵による暗号化と署名の話
初めに 公開鍵による暗号化と署名をプログラマ向け(?)に書いてみました。ちまたによくある暗号化と署名の話はインタフェースと実装がごちゃまぜになっていることが分かり、暗号化と署名の理解が進めば幸いです（と思って書いたけど、余計分からんといわれたらすんません）。登場する言語は架空ですが、多分容易に理解できると思います。 公開鍵による暗号化PKE 早速、公開鍵による暗号化(PKE : Public Key Encryption)を紹介します。登場するのは暗号化したいデータのクラスPlainText, 暗号文クラスCipherText, 秘密鍵クラスPrivateKeyと公開鍵クラスPublicKeyです。PKEは次の3個のインタフェースを提供しています。 abstract class PKE { abstract keyGenerator(): [PrivateKey, PublicKey];
“やります”ドリブンで生まれた負の連鎖を断ち切るために PMの「やるべき業務」「やらなくていい業務」を整理する
PMのはみ出し領域の事例、どこまで対応すべきかについて語る「それってPM業務？みんなの組織のPM担当範囲を聞いてみよう【開発PM勉強会 vol.19】」。ここでアルプ株式会社の前川氏が登壇。PM業務の中で「やらなくていいこと」を決める方法について話します。 前川氏の自己紹介 前川裕一氏：では「業務範囲はどこまで？」という勉強会のところで、「やらないことを決める」みたいな、ふざけたタイトルでやります。アルプ株式会社の前川が発表を始めます。 アルプでPM（プロダクトマネージャー）をやっていて、サブスクリプションビジネスの契約・請求管理の仕組みの「Scalebase」を開発しております。もともとはエンジニアからPMになった枠ということで参加しています。 新卒からモバイルアプリエンジニアをやりつつ、アルプに来てからもバックエンドエンジニアをやって、アルプで2022年からPMにジョブチェンジをして、
【決定版】2022年～2023年で必ず確認するべきGitHubリポジトリ 40選
はじめに 今回の記事では、個人の独断と偏見で2022年～2023年で必ず確認するべきGitHubのリポジトリを紹介する。私のTwitterでこれまで紹介したものもあれば、そうではないものもある。 GitHubはプログラマーにとって、普段の学習・開発を進めるうえでもっとも重要な情報源の１つである。本記事では、分野ごとに確認するべきGitHubリポジトリを紹介する。 なお、今回の記事で紹介するGitHubリポジトリの分野は以下の通り。内容はWeb開発に特化している。 確認必須 Web Python JavaScript TypeScript ちなみに、「確認必須」は分野を問わずすべてのプログラマーに役立つGitHubリポジトリを紹介している。 今回の記事を通して、年末年始の学習・開発に大いに役立ててもらえたら幸いだ。 確認必須 freeCodeCamp 世界最大規模のプログラミングメディア「f
プログラマーに贈る、わかりやすい文章を書くための技法 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 8 の記事です。 転職ドラフトでエンジニアをしている verdy_266 です。 僕の2022年を振り返ると、採用広報チームでの活動を無視することはできません。転職ドラフトの開発を行う傍ら、昨年末に採用広報チームにジョインし、記事の執筆や校正に多くの時間を割いてきました。 今まで記事を投稿したことがなかったこちらのブログにも共作含め5記事を投稿し、11月には Software Design への寄稿の機会をいただくこともできました。文章を書くことが思った以上に好きなんだなと発見があった年でもありました。 made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp 弊
技術者と作業員 - 登 大遊 (Daiyuu Nobori) の個人日記
技術者（エンジニア）という言葉を多用するのは良くないと思う。 最近、特にコンピュータ関連の職業に携わっている者のことを総称してエンジニアなどと呼ぶようになってきている。 しかし、ここ数年間コンピュータ界で色々な仕事や経験をしてきた結果、以下のようなことがわかった。 まず、技術者（エンジニア）と呼ばれる人たちは、２種類に分けることができると思う。 1. 本当の意味での技術者 通常、大勢の人たちが無理だと思っていたり、どれだけ試行錯誤してもうまくいかないような (たとえばコンピュータに関連する) 技術的な難題を、人並み外れた凄まじい問題解決能力で解決し、たちどころに目的を達成してしまう能力を持つ特殊な人たちのこと。多くの場合、置換不可能である。誰でも勉強すればなれる訳ではない。 2. 作業員的な技術者 上記を除いたその他大勢の、コンピュータに関する仕事に携わっている人たちのこと。たとえば特殊な
【プログラマー必見】情報収集で絶対に役立つIT企業の公式ブログ 30選
はじめに 今回の記事では個人の独断と偏見でプログラマー向けに必ず確認しておきたいIT企業の公式ブログを共有する。なお、今回の記事で紹介している公式ブログはあくまで一例に過ぎない。 AppBrew 文章が易しく初心者でも読みやすい 主に業務効率化を中心に書かれている 実務・プログラミングのイメージができない初心者や新人には非常にオススメ ABEJA Tech Blog 主に保守・運用を中心に発信している ドローン・機械学習に興味があるならオススメ 専門用語が多めなので理解に苦労する可能性が高い UUUMエンジニアブログ あの有名なクリエイター(YouTuber)を数多く輩出している会社「UUUM」の公式ブログ Rails・PHP・インフラ(AWS、Dockerなど)の情報が多い 技術記事が非常に読みやすく、画像とソースコードを使って的確に技術ややっていることを説明している Wantedly
【決定版】プログラマーが情報収集で必ず確認するべきWEBサイト 8選(2022年10月時点)
はじめに 今回の記事では、プログラマーが情報収集で必ず確認するべきWEBサイトを8つ一覧形式で紹介する。本記事の読者の対象は主に以下の通り。 プログラミング初心者 情報収集で困っているプログラマー 他のプログラマーの情報収集を参考にしたいプログラマー 効率よくプログラミング学習を進めたい人 プログラミング学習を楽しくさせるサイトを知りたい人 freeCodeCamp.org 世界最大規模のプログラミングメディア「freeCodeCamp」の公式サイト。8,000以上のチュートリアルがあり、しかも無料でPythonやJavaScriptなどのプログラミング言語の基礎的な文法、機械学習、WEB開発やモバイル開発などをこの１つのサイトで体系的に学べる。プログラマーは全員このサイトを確認するべきである。 GitHub 世界中のプログラマーがソースコードを共有したり、共同でプロダクトを開発したりする
プログラマーのための行動経済学 (自信過剰とリーダブルコード) - techtekt
はじめに サマリー 記憶に対する自信過剰 対策 チームや組織で失敗を防ぐには？ 1. 読みやすいコードを書くためのコストを下げる 2. 読みやすいコードを書くことを（ゆるく）強制する まとめ 参考文献 ※三浦は退職していますが、本人の同意を得て、掲載を継続しています。 はじめに こんにちは。パーソルキャリア株式会社でデータアナリストとして働いている三浦です。 私はデータアナリストとしてこの会社で働いておりますが、それと同時に行動経済学の研究もしています。 行動経済学は端的に言えばより「人間くさい」仮定をとりいれて経済学的な分析を行う分野です。 例えば、先延ばしをするとか、楽観的な予想をするとか、情報を無視するとか、人の目を気にするとか、色々です。 修士から数えるとプログラミングは 9 年ぐらい行ってきました。 その過程で、様々な失敗もしてきました。 中には、誰もがしたことのある失敗もあるか
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
ブログ: 良いプログラマは借用し、優れたプログラマは盗む
Stack Overflowのブログより。 コピー・アンド・ペースト(コピペ)は危険な場合がありますが、不注意にソフトウェア開発を行うと、ソフトウェア開発の多くの側面でも危険が伴います。この投稿では、コードのコピーがソフトウェアの開発にとって実際に何を意味するのか、良いコードの盗用が何を意味するのか、そして間違ったコピーの落とし穴について見ていきます。 BY ライアン・ドノヴァン プログラマの間では公然の秘密ですが、ここStack Overflowの回答の一部として投稿されたサンプルコードの中には、本番のコードになってしまうものもあります。もしかしたら、質問をしたことで、完璧なforループを手に入れたかも知れません。もしかしたら、あなたのアプリケーションにぴったりの正確なasync awaitの実装がすでにあるとする素晴らしい答えを見つけたかもしれません。 DEV Community 👩
もうじき40代なかばを迎えるプログラマーの遺言（少し追記）(もうちょっと追記）(さらにもうちょっと追記)
世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。 世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる（ブラック的な意味ではなく）。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説にしか映らないだろう。 だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。 だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。 まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたく
主にターミナルですごすための個人的開発環境
モチベーション ターミナルからなるべく色んなことやりたい。動きたくない。冬のこたつみたいな感じ。 前提 MacとArchでだいたい似たような環境が作れたので対象OSはそのあたりです。 まえがき 色々情報交換や情報収拾するうちに 少しずつ自分の開発環境が変わってきたので現時点のスナップショットとして書いてみたくなった。 dotfileの延長でしかないため自分の秘伝のタレであり、自己満感が強い。 他人の参考になるかは分からないけど、なれば幸い。 逆にこういう記事書くと教えてもらえたりしないかな(打算) とどのつまり？ https://github.com/yyYank/dotfiles あたり。 iceberg tmux zsh zsh-autosuggestions zsh-syntax-highlighting zsh-completions zsh-history-substring-s
大学に行かずにコンピュータサイエンスを学ぶときに優れている教科書や講義映像はどんなものがあるのか？
急速なIT化の進行によってエンジニアが不足しており、情報系の学位を取得せずに独学やプログラミングスクールを通してエンジニアになる人も増えています。そうした人たちがコンピュータサイエンスを学ぼうとしたときにおすすめの分野や本・オンライン講義などが「teachyourselfcs.com」というサイトにまとめられています。 Teach Yourself Computer Science https://teachyourselfcs.com/ ◆コンピュータ・アーキテクチャ コンピュータが実際にどのように機能しているのかをしっかりとイメージできなければ、安定した抽象化を行うことはできません。この分野を学ぶのにおすすめなのは「コンピュータ・システム ～プログラマの視点から～」という本で、タイトルに「プログラマの視点から」とついている通り、高速で効率的で信頼性の高いソフトウェアを作成するという目的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いソフトウェアとコードレビュー / Good software and code review
