「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘 - valid,invalid
時折、「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚がはたらく。ソフトウェアエンジニアの勘といってもいい。 FizzBuzz Enterprise Editionはプログラマジョークとして解されるが、実際のエンジニアリングではもっと微妙な形で表れる。たとえば設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき、提案を実装した結果として管理すべき状態やコード量が減ったりする。(関連: 状態、結合、複雑性、コード量の順に最適化する - valid,invalid) あるいはシステム要件や仕様について話す中で表出することも多い。「新しい画面を作ってこういう情報を見せたい」であったり「ツールAと双方向に同期して検索したい」といった言葉からよくよく要求を聞いてみると、既存機能で代替ができたり、大仰なインテグレーションは不要だと気づく。 不要な仕事を減
AIにプログラミング作業を奪われている - k0kubun's blog
せっかく10年以上かけて学んだプログラミングだが、人間がコード書くよりChatGPTにやらせた方が早いなということが度々あり、だんだん自分でプログラミングをやる時間が減ってきた。AIにコードを書かせてそれをGitHubにコピペして残りの時間は遊んでるだけで成果が出てお給料ももらえる日は近いし、段々会社もそのことがわかってきて失職する日も近い。 残念ながら現時点では全ての仕事がAIで上手くいくわけではないが、どういう時に使えるかを知っておくと楽をしやすくなるので、僕がどう使っているかをまとめておく。 失職できるケース 簡単なスクリプトを高速に書かせる 僕はRubyが全ての言語の中で一番慣れており、StackOverflowやドキュメントをほぼ見ずに大抵のプログラムを書き切れるため、Rubyを書いている時がプログラマとして一番生産性が高いのだが、それでも最近AIにRubyを書かせたことがあった
ノーコードの限界は意外と近い まつもとゆきひろ氏が語る、プログラマーが仕事する相手は“人間”ということ | ログミーBusiness
数多くのプログラミングスクールが立ち並び、小学校でもプログラミング教育が始まったことからも、重要度が高まっているプログラミング。一方で、プログラミングを必要としない“ノーコード開発”にも注目が集まっています。 ノーコード開発が普及すれば、プログラミングに対してハードルが高く感じていた方も触れやすくなる一方、ブラックボックス化などの懸念点もあるでしょう。そこで今回は、Rubyの生みの親であるまつもとさんに、ノーコード開発のことを踏まえながら、言語を学ぶ意味、プログラマーの仕事について質問しました。ここからは、プログラミング教育とプログラマーの仕事について。前回はこちらから。 ノーコードの限界は意外と近いーー小学校でプログラミングを勉強することになったり、プログラミングスクールが増加したりと、プログラミング自体はより普及が進んでいる時期だと感じます。そんな中で、ノーコード開発が普及することに、
設計に悩みすぎる前に手を動かしてみる話
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
Go言語を嫌う6個の理由 - さめたコーヒー
ある仕事でそれまでRubyで書かれていたサーバーサイドをGo言語ですべて書き直すことになって、それまでRubyのコードを書いていた僕はそのままGo言語を書くことになった。その仕事そのものはお客様（僕は外部委託のエンジニアとして参画していた）との関係も良好で素晴らしい仕事をさせてもらうことができたと思っているが、Go言語だけは好きになれなかった。 はじめは流行っている言語だから何か素晴らしい魅力があるのではないかと期待していた。しかし書き始めるうちにどうも自分には合わないなと思うようになり、2年ほど書いて案件の契約が終わる頃にはGo言語でサーバーサイドを書くことは危険だとさえ思うようになった。 あれから数年がたちますますGo言語の案件は増えている。サーバーサイドを書く選択肢としてGo言語を選択する会社も増えている。しかし本当にそれでいいのか？ただ流行っているからという理由だけで選択するにはあ
LeetCode - The World's Leading Online Programming Learning Platform
Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
コードリーディングのコツは極力コードを読まないこと｜牛尾 剛
私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど
freedesktop.org.xmlの著作物性 - 西尾泰和の外部脳
mime-typeに関する「データベース」であるfreedesktop.org.xmlに著作物性があるかどうか、という話。 例えばそのデータベースが下記のようなものだったら、これは単なる網羅的な事実の列挙であって、体型的な構成に創作性がないので「データベースの著作物」としての保護の対象にはならない。
向上心を持つのは大事だけど技術を殺すのはやめようね - srockstyle - Webと創作が好きなふつうの人です。
毎年なにかを殺さないと気が済まないエンジニアのみんなが書いたなんとかis deadの記事をまとめてみた。 PHP id deadPHPはもうすぐ死ぬPHP is deadその2CakePHP is deadRuby is deadRuby is dead? 2019Ruby on Rails is dead?2019Ruby on Rails is deadRuby on Rails is dead?その1Ruby on Rails is dead?その2Ruby on Rails is deadその3Python is deadReact is deadnodejs is deadJava is deadGCP is deadVim is dead 2013emacs is dead 2014emacs is dead （英訳） 所感 現在使われている技術を死んだとかもうだめとかいうのは
ノーコードは形を変えた現代のRPGツクールなのではないか
この記事について。 2030 年 「エンジニアです。コードは書けません。」｜__shinji__｜ note 自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。 はじめに、ノーコードを分類する 本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。 その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。 タイプ 1: データベースから自動的にフォームを生成 Google App Sheet MS Power Apps タイプ 2: 高水準 API のパイプライン Zapier IFTTT 古の Yaho
コードを書くには連続した2時間が必要 - hitode909の日記
ある日の午後のスケジュールは、30分ミーティングx2→30分自由時間→そして1.5時間ミーティング、その後は30分自由時間と30分ミーティングを繰り返して定時を迎える…みたいな様子だった。案の定、自由時間で意味ある仕事を進めることはできなかった。 自由な時間が30分あれば、チャットを読んだり、コードレビューしたり、グループウェアを見て回ったり、とかはできる。コードを書くにしても、ここをこう変えれば良いことがわかっていて、書くだけ、とか、ライブラリのバージョンアップ、くらいなら30分で書いてpushしておいて、次の30分でテストが落ちたら直したりして、と進められる。 しかし、そういうことより難しいことをしようとすると、30分だと、さて、問題がどういうものかは分かってきたので、どうしようかな、というあたりで時間切れになってしまう。1時間あれば、ようやくコードを書き始められるかな、というところで
28. 技術選定の審美眼(1) w/ twada | fukabori.fm
話したネタ Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition フロントエンド疲れとは？ 大筋でのトレンドは変わってないが、目が養われていないと疲れてしまう Gruntとgulp.js、ReactとVue.js イメージ的には選球眼 変わるもの、変わらないものを見極めるモチベーションは何か？ 技術の世界は変化が緩やかで手堅い部分と変化が激しい部分がある 振子のように見えていた変化は、角度を変えて見れば螺旋であり、その差分を見るのが大事 ベテランエンジニアの唯一のアドバンテージとは？ プログラマとしての可処分時間はどんどん減っていく ベテランプログラマに求められる役割としての、語り部と老害のボーダライン Unix哲学 小さいのは良いことだ(Small is beautiful) 一つのことを上手くやる(Make each program
【転職エントリ】Googleに入社します｜Lillian
はじめに この記事には、Googleのオンサイト面接に向けて勉強した内容が記載されていますが、それらはすべて面接を受ける直前に書いておいたものです。このエントリを読むことで面接で聞かれた内容が予測されてしまわないようにそのようにさせていただきました。ご了承お願いします。 この記事について 令和元年に医師を退職し、ソフトウェアエンジニアに転職します。 自分にとって大きな転機であったのと、とても大変な道のりであったので、私という人間が辿った道筋を最初から最後までちゃんとまとめておきたいと思いこの記事を書くことにしました。 私のような他業種から未経験での転職を目指されている方にとっても、何らかの参考になる内容であれば幸いです。 私の生い立ち 私は小さい頃からテレビゲームが大好きで、学校から帰るとずっと家でゲームをしている子でした。あまりにもゲームが好きだったので、遊ぶだけではなく自分で作ってみた
プログラマーを30年間やってきた経験から学んだことまとめ
プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちいさな Web ブラウザを作ってみよう
Zenn｜エンジニアのための情報共有コミュニティ
shiodaifuku.io
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
