プログラマyasuhoの隠れ家

某ソフトウェア企業に勤務するおじさんプログラマyasuhoです

プログラマが転職する理由

エンジニア、妖精さんみたいな存在なので、面白そうなプロジェクトとか良いPCとかディスプレイとか椅子とかを置いておくと自然と会社に集まってきてせっせと働いてくれます。

逆に硬い椅子とかしょぼいPCやディスプレイとか自由を奪う規則とかが増えるとエンジニアさんは会社から去っていきます

退職エントリーを書かれる前に実践したい、エンジニアが辞めないチームの作り方 (1/3):エンジニアは妖精さん - @IT

妖精さん(笑) あー、たしかに妖精みたいなものかもねー、プログラマって。

ただ、この記事で気になったことが一つ。

それは

「不満になったから退職した」が前提になっていること。

まあ多くの場合は不満があるから退職/転職するんだと思う。でも、プログラマが転職する理由はそれだけじゃなくて、向上心や、新しいチャレンジをしたいという気持ちから転職する場合だってある。それは一部の人だけではなく、わりと多いんじゃないかと思ってる。

ご存知の通り

この業界は変化が激しい。5-6年前に主流だった技術が今はlost technologyなんてことは普通だ。その中でプログラマを続けていくには、常に新しい技術をキャッチアップしつつ、自らの技術力を磨いていかないといけない。

そういう環境にいると、より新しいチャレンジをしてみたいと思うのは自然なことだと思う。現状に不満がなかったとしても、一箇所にとどまっていることが不安になってくることだってあるだろうね。

あと

個人的にはネガティブな気持ちで転職したくないんだ。まあ自分が楽天家ってこともあるんだけど、新しいことにワクワクしたいって気持ちでいないと、前に進めない。過去のことで悩んだって、しょうがないって思うようにしてるんだと思う。

新しい企業だって、不満だけの人を採用したいとは思わないんじゃないかな。今の職場が不満で、どこでもいいから逃げたいって気持ちは相手に伝わる。そして、今自分はどれだけ新しいチャレンジにワクワクしてるかって気持ちも伝わるよね。

記事にも書いてあるけど

最終的には、ぶっちゃけ不満の多くはお金でしか解決できないんだと思う。自分はこれだけ頑張ってるんだから、このぐらいはもらいたい。という線がどこにあるかって話だよね。

いわゆるGAFAMと呼ばれる企業が、優秀な人に快適な環境と高給を与えているのは、優秀な技術者を一人でも多くつなぎとめたいってこと。少しずつだけど、日本もだんだんそうなってきてる気がする。

資金力のある大企業でないと

優秀な人を高給でつなぎとめるってことは難しいかもしれない。けど、いろんなチャレンジが出来る会社だってことが認知されると、集まって来る妖精さんも増えてくると思う。企業としては利益も追求しないといけないから、いろいろ難しい面もあるとは思うけど、そんな企業が増えてくれることを願っています。

ねえ、ちょっとやってみて!?

また、私が初心者のころ
優秀なプログラマーになるためにはアルゴリズムが必要
と思ってアルゴリズムを勉強した覚えがあります。

しかし、今思えば
学習コストのわりにあまり役立たない知識
だったなという印象です

アルゴリズムの勉強は必要か?不要である3つの理由

私がプログラミングを学び始めた頃は、今のようにコンピュータは普及しておらず、何をするにも自分で作る必要があったように思います。WindowsMacといった、統一された環境もなく、リコンパイルすれば動くといったことはほぼ皆無でした。プログラムを他のプラットフォームに移植するには、プログラムが何をしているのかを理解し、アルゴリズム部分だけをリライトする必要がありました。何か問題があっても情報は雑誌や本を調べるぐらいしかなくて、何日も思い悩むということは日常茶飯事。

いきなり年寄りの昔話ですいません(笑)

そんな不便極まりない環境ではありましたが、今思えば幸運な時期にプログラミングを始めることができたな、と思います。プログラムというものがコンピュータの中でどうやって動き、どう書けば自分の思うように動くのか、体験することができたから。コンピュータの作りが単純で、プログラムを書くことが簡単なのも良かった。CPUの速度が遅いから、どうすればプログラムを効率よく書けばいいのかが分かる。こういったことは、プログラマとなるために良い経験になりましたね。

とか書いてたら

ふと「自分のプログラミング能力って、どの程度なんだろう」って思って、競技プログラミング系のサイトをいくつか試してみました。やってみたのは:

TopCoder
HackerRank
LeetCode

とかですね。

そしたら…

これが思ったほど出来なかったんですよ。プログラマなので、毎日コードは書いてるんですよ。慣れもあるみたいで、問題を解くうち段々と書くのは早くなってくるんだけど、でも自分が思うほど書けなかった。

で、思ったのは、自分はできると思っていても、普段からやってない能力は衰えるってこと。毎日プログラムを書いているって言いましたけど、業務のプログラミングって、分野によって書くプログラムって大体決まってるからかな。例えば私の場合は組み込み系が多いんで、システム寄りのプログラムを書くことが多く、一般的なアプリケーションを作ることはあまりしないです。なので、なおさらプログラミングスキルとしては偏ってるんだろうな、って思います。

別に何でも出来るようになる必要はないと思います。私も先の記事を書いたネットサーフィンの壺さんが言われるように、必要になった時に学習すればいい派です。でも新しいことを学ぶことはそれなりにコストがかかります。ディープに学ぶ必要はなくても、それをどれだけ短い時間でものにできるかは、日々の鍛錬が欠かせないのだな、と感じました。

競技プログラミングのサイト

興味があったら、ぜひやってみて下さい。え!?「こんなの簡単だよ」って!?えっと、精進します^^;

Google Home買って一番よかったこと

もう1年以上前になりますが、Google Home Miniを買いました。

store.google.com

スマートスピーカーに興味があったのと、ちょうど半額セールやってた時で、安かったことが購入理由。3,000円ぐらいだったかな。色はチョーク(シルバーっぽいやつ)を選んだ。

最初はいろいろ話しかけてたけど

すぐに飽きた(笑) リアクションもそれほど多くなく「すみません。よく分かりません」も多く出る。当時はまだ出始めだったから「まあこんなものかな」と思って、そのまま放置された。

そんなGoogle Homeの使いみちを見つけたのは

ラジオだった。

Google Home, ラジオとして、とても優秀。つまりradikoなんだけど、「OK Google, NHK第二」と話しかけるだけで、NHKラジオ第二が再生されるのは、とても便利。しかもminiだからモノラルなんだけど、音はクリアで、とっても聞きやすい。さすがスピーカー :)

パソコンでradikoとか聞いたことがある人は分かると思うけど、パソコンのスピーカーって、部屋全体に聞こえるようになってないのが多い。あとradikoとかのwebアプリはそれなりにCPUを使うので、意外にファンの音が気になったりする。これらをクリアしてるGoogle Homeは普通のラジオを使ってる感覚に近い。

使い勝手として気になるのは

やっぱり「OK, Google」って話しかけないといけないことかな。まあ、そりゃそうなんだけど、例えばラジオ聞いてて電話かかってきたとするじゃない。そうするとOK, Googleするんだけど、近くにいないとラジオの音にかき消されて反応してくれないから、近くに行って話しかけるか、スピーカーを持ち上げないといけないわけです(スマフォからオフするとかも出来るけどね)まあ当たり前なんだけど、意外とこれがストレス。

将来は音声だけじゃなく、カメラなどの各種センサーを備えたものになってくのかなあ、なんて思ったり。

そんなわけで

我が家ではすっかりラジオになっております。ラジオ好きなら、きっと気に入りますよ、スマートスピーカー :)

Windows Mobileはなぜ終了したのか

とうとう正式に終了が告知されたのね…

 米MicrosoftはモバイルOS「Windows 10 Mobile」のサポートを2019年12月10日に終了する。1月3日に公開したサポートページのFAQで告知した。

「Windows 10 Mobile」12月10日にサポート終了「AndroidまたはiOSへの移行をお勧め」とMicrosoft - ITmedia NEWS

正直に言えば

今のスマフォベースのは一度も使ったことはないんだ。使ってたのはWindows CEベースのWindows MobileW-ZERO3シリーズで使ってた。その後ソフトバンクの005SHに乗り換えてからは、ずっとandroid.

Windows Mobileは正直言って使いやすいわけではなかったけれど、Visual Studioでアプリを作ったりして、それなりに自分で使いやすくできて、けっこう楽しかったな。

androidでは初期にeclipseベースのIDEでちょこっとサンプルを作ったぐらいで、アプリは作ってない。正確に言えば、自分が欲しいと思ったものは、誰かがすでに作っていて、google playからすぐにダウンロードできる。やっぱりworld wideでアプリを配布する環境があるってのは、いいよね。

自分なりにwindows mobileの敗因を分析すると

市場への投入が遅すぎたことに尽きるんじゃないかと思う。たしか開発を表明してから市場に投入されるまで、2年近くかかったんじゃなかったっけ。アプリ開発からしたら、プラットフォームは2つまでが限界だろう。もう少し市場投入が早かったら、androidにリーチする可能性はあったんじゃないかなあ…

自分では使ってないから、的外れなこと言ってるかもしれないけど。

ともあれ

一つのプラットフォームが消えるというのは、寂しいものがあります。今後はandroidiOS(特にandroid)でリリースされるアプリに期待してますよ、マイクロソフトさん :)

とうとう夢が叶う日が来る!

これは買わねばなるまい。

パソコンミニとは、1978年以降に大ヒットしたマイコンを約1/4サイズで再現した手乗りコンピュータ。ラインナップは「PC-8001」、「FM-7」、「MZ-80C」の3機種。小型ながらその筐体は非常に精巧で、これだけでも所有欲をそそる。内部にはRaspberry Piを搭載しており、各機種のエミュレータが動作する。しかも、プチコンで採用されているSmileBASICが実装されている。エミュレータはオンメモリのプログラムが動くレベルのもので、テープやFDDなどの制御機能はない。

PC-8001やFM-7、MZ-80C……懐かしのパソコンがミニサイズで現代に甦る! ハル研究所が発表した「PasocomMini」の詳細と狙い - AKIBA PC Hotline!

よくぞ作ってくれました!ハル研と言えばカービィではなくPCGを連想してしまうオジサンですが、いや素晴らしいですね。

記事にあるように、権利関係とか大変だったんじゃないかと思います。BASICを搭載していないのは残念ですが、それ故にエミュレータと連携できるSmileBASICということなのですね。

というか記事ではさらっと書いてますけど、RasPiで動くSmileBASICって、それだけで売り物になるのでは。3DS持ってないので、もうそこだけでも買いですよ。どうか単体販売もご検討いただければ幸いでございます>スマイルブーム様 :)

とはいえBASIC-ROM搭載は何とかならないでしょうか。最初にこの記事を見た時「高校時代に作った自作FORTRANコンパイラが動くかも!」って思ったんですけど、BASIC非搭載を見て挫折。このコンパイラはROM内ルーチンをコールしまくってる上にFORTRANソースコードをBASICのコメントで入力する*1ので。これに限らず、当時のソフトでBASIC-ROM使ってるのって多いと思います。大変だとは思いますが、どうかお願いします!>ハル研究所

昔妄想Watchってウェブサイトがあったんですけど

そのサイトにゲームボーイアドバンスの形をしたMZ-80Kってのがあったんですよね。こんなのがあったら欲しいな、なんて思ってたんですが、その夢がついに叶うなんて感無量です。昔こことかこことかこことかで妄想していたなー、なんて思ってました。

そういえば妄想Watchってサイト、もうないのですね。ウェブアーカイブとか探せばいいのかな。

既にエミュレータとかあるわけですが

たいていはROMイメージの吸い出しのために実機が必要なわけで、もう既に実機とか持ってない私には使えないわけですよ。まあこのフォルム見ただけで買うことはほぼ決定なんですけどね。こういうのを応援して、レトロPC界をどんどん盛り上げていきたい、って思いもあります。これもエミュレータではあるのですが、やっぱり形って大事だと思うのです。

問題はどれを買うかですが

いやー悩ましい。順当に行けば最初に買ってもらったマイコンであるPC-8001なんだろうけど、せっかくだからPC-8001とどちらを買うか迷ったMZ-80Cというのもいい。いつも"MONITOR SP-100?"の画面しか見たことなかったしね。はたまた憧れのCPUだった6809を搭載したFM-7というのも捨てがたい。YAMAUCHI試してみたい。

全部買えばいいんじゃないかって?そんなことしたらヨメさんに怒られます^^; ウェブでも言われてますが、やっぱり筐体のみでも販売して欲しいかな。RasPiは手持ちのを使うと。そしたら全部買えるかな :)

というか、本当は40年近く前のあの雰囲気を楽しんでみたいんですよ。ナイコン*2だった頃、秋葉原でもらってきたカタログや雑誌の広告を食い入るように見ていた。買ってもらうことになってからも、どの機種にするか悩みまくったっけ。でもそんな日々もけっこう楽しかったんだよね。21世紀にもなってこの気持が味わえるなんて、楽しいではありませんか :)

と言いつつ、玉砕覚悟で全部買ってしまうかも ^^;

*1:TL/1方式

*2:マイコン持ってない人のこと

インテル8080伝説を読んだ

いしかわさん投稿を見て「これは買わねばなるまい」と思い、購入しました :)

インテル8080伝説

インテル8080伝説

購入したのが発売されて間もなかったせいか、CD-ROM付きの初版をゲット。このCD-ROMにはなんと本書と全く同じ内容のPDF(しかもオールカラー!)が収録されていたので、PDF版を読んだ。本書はページをめくってすらいない(笑)

初版のみCD-ROMが付くということだが、出版社の購入ページから直接買えばCD-ROMがもらえるみたい。

さて

その内容ですが、70-80年代のマイコン世代であれば当時の空気を感じられることは間違いない。のですが、本書の肝は8080マイコンを作る!というところにあるので、ハードウェアの知識がないとちょっとツライかも。かく言う私は電子工作のところはイマイチ分からなかったです。

とはいえ、なるべく当時のノリで作ってみようという著者の心意気は十分に伝わります。そうそう、当時のマイコンは命令サイクル数からクロックが計算できたんだよな。EPROMに焼く時はインテルHEXフォーマットを使うんだっけ。そんな当時のことを思い出すことが出来ました。

最初に触れたコンピュータが、こういった素直な設計のハードウェアだったことに今更ながら感謝です。コンピュータの学習に大きな苦はなかったものね。これが今のマイコンクラスだったら、イヤになって投げ出してしまってたかもしれない。

そういえば

今回始めて池袋のジュンク堂書店に行ったのですが、ここのコンピュータコーナーはいいですね!整然と並べられた書棚に豊富な雑誌のバックナンバーの数々を見ていたら、かつてコンピュータの本を買うために足しげく通った神保町の書泉グランデを思い出しました。お気に入りの本屋さんになりそうです :)

プログラマに必要なスキル

私も自分なりに、プログラマとして必要なスキルをまとめてみる。

エンジニアにとって最も大切なことは、お腹が出ていないこと。
と、15年前に私の見ていたサイト界隈で決着がついたのですが、エンジニアである私が必要だなと思うスキルって自分の中では時折変わっているので並べてみます。

エンジニアに必要なスキルは - まなめはうす

要約すると

ソフトウェア開発という仕事は「問題を調査し、原因に対する最適な解決策を考え、それを実現するコードを書いて問題を解決する」のループであると思う。これはバグ修正に限らず、ソフトウェア開発の全ての工程において言える。

といった観点から

私の考える「プログラマに必要なスキル」をまとめてみる。他にもいろいろあるけど、それは他の機会にでも :)

ソフトウェアを作るために必要な情報を探し出すスキル

プログラマであれば「こんなのをxx/xxまでに作って」と言われたことは経験にあるだろう。いや、大体そうか(汗)

それはググればすぐ分かることかもしれない。けど、大抵それは周りに詳しい人もいないようなことで、どこから手を付けたらいいか分からない。そんな時、大量の情報から必要な情報をピンポイントで見つけ出し、ソフトウェアをデザインする能力は重要だ。

そのためには色々なことに興味を持ち、情報収集を怠らない努力が必要だと思う。とはいえ、人間は全知全能ではないので、その分野に得意な人とコネクションを作っておくことも必要かもしれない。

動作するコードを素早く仕上げるスキル

これは id:maname さんの意見に賛成。testableなコードをいかに素早く実装できるかはプログラマにとって重要なスキルだ。

ここで重要なのは、単にコーディングの速度が早いというだけではなく、設計段階でどこまで実装を意識した仕様に落とし込めているかということだと思う。「ん?このケースはどうやって実装すればいいんだっけ?」というのを、いかに減らしておくかの方が重要なように思う。いくらタイピングが速くても、仕様変更ばかりではかえって時間がかかってしまうよね :)

何が問題なのかを突き止めるスキル

ソフトウェア開発に限らず、コンピュータを使っていると、様々な問題に遭遇する。それが自分が作ったモジュールであればいいが、実際にはどこに問題があるかも分からないことが多い。もっと言えば、ソフトウェアの問題だけとは限らない。

そんな時、当たりをつけて問題を絞り込み、原因を素早く発見する能力は重要だ。これについては経験を積む以外、いい方法が思いつかない。一緒に問題を調べてくれる、職場の同僚やその分野のエキスパートとのコネクションが、実は一番重要なのかも。

問題に対して最適な解決方法を提示できるスキル

問題の原因は見つけた。さて、どうやって解決しよう。単純なコード修正で終わることも多いが、複数のソリューションがある場合も少なくない。いや、そもそも思い込みから他のソリューションがあることに気がつかないこともあるだろう。

パフォーマンス、コードサイズ、データ量、プラットフォームにおけるバランス、互換性への配慮、などなど様々な条件から複数のソリューションを考え、その中からベストを提案できることは重要なスキルだと思う。とはいえ、全てを一人で決めることがベストではなく、複数の識者の知見をふまえて解決方法を提案できる人の方が優秀かもしれないと、最近は感じている。

とか書いてきたけど

出来てたら、こんなに苦労してないわ!あー、こんなプログラマに私はなりたい(笑)