withコロナ時代のフリーランスエンジニアの生存戦略｜shu223
フリーランスでiOSエンジニアをやっています。実はこのコロナ禍のちょっと前、今年の始めぐらいからお仕事が減ってきていました。昨年は常時5〜7クライアントとお付き合いがあったのが、2クライアントに。 いやいや、クライアント数が減ったぶん、それぞれのお客さんのお仕事をじっくり取り組めるようになったし、やりたくても時間がなくて後回しになってしまっていた新しい技術分野の勉強もできる。全然平気だわ〜と過ごすこと3ヶ月。 （いやまじで新規の仕事の依頼来ないんだけど.......え？これってコロナの影響？それとも単純におれがオワコン？確かに単価は高いし仕事は選ぶしわりと必須な技術をキャッチアップしないしで、技術のコモディティ化が早く参入障壁が低く常に優秀な若手が出てくるこの世界、いつ需要がなくなってもおかしくないしな...） と、ちょっとずつ不安になってきました。 そこで試しにやってみてうまくいったのが
僕の個人開発を成功に導いてくれた本たち
A must read for anyone building a web app. Getting Real is packed with keep-it-simple insights, contrarian points of… この本は僕が個人開発者として進むべき方向を照らしてくれました。今でも繰り返しメモを読み返しています。かつての僕はアントレプレナーシップやスタートアップ文化に強く影響されていて、「スティーブ・ジョブズみたいにビッグになるぞ！」とか「facebookみたいな世界を席巻するサービスを作らなきゃ！」と息巻いていました。イタイ。同書は世界を獲ってビッグになることだけが成功の道ではなく、他にもソフトウェア開発で人生を謳歌できる方法がある事を教えてくれました。これはSaaSビジネスの立ち上げを、より少なく、本当に重要な事にだけ取り組む事で成功に導く方法について解説した本で
Secure the software development lifecycle with machine learning
Every day, software developers stare down a long list of features and bugs that need to be addressed. Security professionals try to help by using automated tools to prioritize security bugs, but too often, engineers waste time on false positives or miss a critical security vulnerability that has been misclassified. To tackle this problem data science and security teams came together to explore how
#22 Gitメンテナ 濱野 純 | gihyo.jp
今回のゲストは、分散バージョン管理システムGitのメンテナで『入門Git』（注1）の著者、濱野純さんです。Linuxカーネルの開発者、Linus Torvaldsさんから引き継いでGitのメンテナになった経緯から、対談スタートです。 （撮影：武田康宏） Gitに関わった経緯 弾：Gitに関わったきっかけは？ 濱：2005年の4月にLinuxカーネルのバージョン管理システムとして使われていたBitKeeperが使えなくなる[2]からということで、Linus君がいろいろありものを探したんだけど、使えるものがなくて、誰かがいいのを作ってくれるまでのつなぎというつもりで、とりあえず自分でもコードを書いた、というアナウンスをしました。それをカーネルメーリングリスト（ML）で見ていたんですが、たまたまボクの本業がプロジェクトとプロジェクトの合間だったんです。なんかおもしろそうなこと始まってるじゃん、
Software Engineering at Google
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their codebase sustainable and healthy. This boo
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
【翻訳】個人開発のプロダクトを6ヶ月で売却するまで - NOT SO BADなブログ
【翻訳】個人開発のプロダクトを6ヶ月で売却するまでDec 22, 2019 個人開発論翻訳新年に日本のお寺で（右が著者です） この記事はイギリスのIndie Hacker（個人開発者）、Josh（@joshahowarth）のブログ記事を、本人の許可を得て翻訳・掲載しているものです。 オリジナルの記事はこちら↓↓ 個人開発のプロダクトをいかに育てていくか、海外のIndie Hacker事情も垣間見えてとてもおもしろい記事です（長いけど）。Product HuntやRedditなど、海外のローンチプラットフォームもたくさん出てくるので、馴染みがない方は先に以下の記事を読んでいただけるとよりイメージがつきやすいかと思います。 同じくIndie HackerのPieter Levesの記事です。今回のJoshも非常に参考にしているらしく、記事内でも何度か言及されています。 多分に意訳していますが
なぜ未曾有の人材不足でも、エンジニアの年収は上がらないのか
なぜ未曾有の人材不足でも、エンジニアの年収は上がらないのか：多重下請けも海外人材活用も「元」は同じ（1/3 ページ） 市場原理では需給バランスで価格が決定する。なのになぜ、俺の、私の年収は上がらないんだ！――IT“業界”解説シリーズ、第7弾はマクロ視点での多重下請け考察です。 複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを、第4弾はユーザーはなぜプロジェクトに協力したがらないのか、第5弾は「案件ガチャ」が起こるメカニズム、第6弾はベンダーの営業が安請け合いする理由を説明しました。 今回は、再び「多重下請け構造」について考えます。 就活時、偏った業界研究をしてIT業界に就職したITエンジニアの中には、キャリアアップしたくても、
コードを書いて金を稼ぐ - kuenishi's blog
初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社（割と稼いでいる）で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。なお収入なので税金の扱いを間違えないように。しかし特許といえばガッポガポ…というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズ
「そろそろ本当に何も通用しなくなったって感じ」50～60代のシステムエンジニアやプログラマーを沢山面接していて感じる『IT最初の世代の終末医療』
こゆるぎ岬 @o_thiassos さいきん訳あって50～60代のシステムエンジニアやプログラマーを沢山面接しているんだけど、IT最初の世代の終末医療という感じで、非常にキビしい。技術者は技術だけでは引退まで生きては行けない。つまり「そういう人」たちが今、職を失い、職にありつけない。あと5年10年を生き残れない。キツい。 2019-12-04 19:50:41 こゆるぎ岬 @o_thiassos 高齢ITエンジニア浪人の経歴書を見ていると、約10年前くらいに大手メーカーやその下請をリストラされて、そこで使っていた限定的なスキルが通用するのがITしかなく、なんとか短～中期的な案件を渡り歩いて凌いでこれたけど、そろそろ本当に何も通用しなくなったって感じがある。 2019-12-04 22:34:46 こゆるぎ岬 @o_thiassos 「使えないオッサン」に、事実として、社会は容赦がない。また
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
ソフトウェア系国際規格の認証の現状について
機能安全規格の IEC 61508(Functional safety of electrical/electronic/programmable electronic safety-related systems) や ISO 26262 (Road vehicles — Functional safety )や、医療機器ソフトウェアのソフトウェアライフサイクルプロセス規格 IEC 62304(Medical device software - Software life cycle processes)に 「適合しました！」とか、「準拠しています！」といったニュースリリースをよく見る。 しかし、ブログでは『汎用ソフトウェア製品（製品開発プロセス）は IEC 62304(JIS T 2304) に適合できない』で書いたように、医療機器ソフトウェアでは、汎用ソフトウェア製品や汎用ソフトウェ
「測定できないものは制御できない｣は誤りだった。-- by Tom Demarco：An Agile Way：オルタナティブ・ブログ
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
SQLインジェクション対策不備の責任 東京地判平30.10.26（平29ワ40110） - IT・システム判例メモ
SQLインジェクション対策をしていなかったことについて開発会社の責任が問われた事例。 事案の概要 Xは，Yに対し，Xの提供する車・バイクの一括査定システム（本件システム）の開発を約320万円で委託し，平成24年9月に納品を受けた。 その後Xは，平成28年12月に，IPA*1から，中国のサイトに本件システムの脆弱性に関する情報が掲載されているという指摘を受けて，Yに対し，その調査と報告を依頼した。 その結果，本件システムには，ＳＱＬインジェクション対策が不十分という脆弱性が判明したことから，XはYに対し，その脆弱性はYの被用者の故意過失によって生じたものであるから，使用者であるYには使用者責任があると主張して，民法７１５条１項所定の損害賠償請求権に基づき，緊急対策費用４７万５２００円，詳細な調査，抜本的な修正費用６４０万円，サーバー移転費用３５万６４００円，セキュリティ対策のための本件システ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア・ファーストの感想 - プログラマの思索
Dos and don'ts in open source
Embedding security, the right way - Help Net Security
The road to Software 2.0
Googleのソフトウェアエンジニアリング文化
The Real Problem with “The Expert”