Google Home買って一番よかったこと
もう1年以上前になりますが、Google Home Miniを買いました。
スマートスピーカーに興味があったのと、ちょうど半額セールやってた時で、安かったことが購入理由。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 MobileをW-ZERO3シリーズで使ってた。その後ソフトバンクの005SHに乗り換えてからは、ずっとandroid.
Windows Mobileは正直言って使いやすいわけではなかったけれど、Visual Studioでアプリを作ったりして、それなりに自分で使いやすくできて、けっこう楽しかったな。
androidでは初期にeclipseベースのIDEでちょこっとサンプルを作ったぐらいで、アプリは作ってない。正確に言えば、自分が欲しいと思ったものは、誰かがすでに作っていて、google playからすぐにダウンロードできる。やっぱりworld wideでアプリを配布する環境があるってのは、いいよね。
自分なりにwindows mobileの敗因を分析すると
市場への投入が遅すぎたことに尽きるんじゃないかと思う。たしか開発を表明してから市場に投入されるまで、2年近くかかったんじゃなかったっけ。アプリ開発者からしたら、プラットフォームは2つまでが限界だろう。もう少し市場投入が早かったら、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世紀にもなってこの気持が味わえるなんて、楽しいではありませんか :)
と言いつつ、玉砕覚悟で全部買ってしまうかも ^^;
インテル8080伝説を読んだ
いしかわさんの投稿を見て「これは買わねばなるまい」と思い、購入しました :)
- 作者: 鈴木哲哉
- 出版社/メーカー: ラトルズ
- 発売日: 2017/02/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
初版のみCD-ROMが付くということだが、出版社の購入ページから直接買えばCD-ROMがもらえるみたい。
さて
その内容ですが、70-80年代のマイコン世代であれば当時の空気を感じられることは間違いない。のですが、本書の肝は8080マイコンを作る!というところにあるので、ハードウェアの知識がないとちょっとツライかも。かく言う私は電子工作のところはイマイチ分からなかったです。
とはいえ、なるべく当時のノリで作ってみようという著者の心意気は十分に伝わります。そうそう、当時のマイコンは命令サイクル数からクロックが計算できたんだよな。EPROMに焼く時はインテルHEXフォーマットを使うんだっけ。そんな当時のことを思い出すことが出来ました。
最初に触れたコンピュータが、こういった素直な設計のハードウェアだったことに今更ながら感謝です。コンピュータの学習に大きな苦はなかったものね。これが今のマイコンクラスだったら、イヤになって投げ出してしまってたかもしれない。
プログラマに必要なスキル
私も自分なりに、プログラマとして必要なスキルをまとめてみる。
エンジニアにとって最も大切なことは、お腹が出ていないこと。
エンジニアに必要なスキルは - まなめはうす
と、15年前に私の見ていたサイト界隈で決着がついたのですが、エンジニアである私が必要だなと思うスキルって自分の中では時折変わっているので並べてみます。
要約すると
ソフトウェア開発という仕事は「問題を調査し、原因に対する最適な解決策を考え、それを実現するコードを書いて問題を解決する」のループであると思う。これはバグ修正に限らず、ソフトウェア開発の全ての工程において言える。
といった観点から
私の考える「プログラマに必要なスキル」をまとめてみる。他にもいろいろあるけど、それは他の機会にでも :)
ソフトウェアを作るために必要な情報を探し出すスキル
プログラマであれば「こんなのをxx/xxまでに作って」と言われたことは経験にあるだろう。いや、大体そうか(汗)
それはググればすぐ分かることかもしれない。けど、大抵それは周りに詳しい人もいないようなことで、どこから手を付けたらいいか分からない。そんな時、大量の情報から必要な情報をピンポイントで見つけ出し、ソフトウェアをデザインする能力は重要だ。
そのためには色々なことに興味を持ち、情報収集を怠らない努力が必要だと思う。とはいえ、人間は全知全能ではないので、その分野に得意な人とコネクションを作っておくことも必要かもしれない。
動作するコードを素早く仕上げるスキル
これは id:maname さんの意見に賛成。testableなコードをいかに素早く実装できるかはプログラマにとって重要なスキルだ。
ここで重要なのは、単にコーディングの速度が早いというだけではなく、設計段階でどこまで実装を意識した仕様に落とし込めているかということだと思う。「ん?このケースはどうやって実装すればいいんだっけ?」というのを、いかに減らしておくかの方が重要なように思う。いくらタイピングが速くても、仕様変更ばかりではかえって時間がかかってしまうよね :)
何が問題なのかを突き止めるスキル
ソフトウェア開発に限らず、コンピュータを使っていると、様々な問題に遭遇する。それが自分が作ったモジュールであればいいが、実際にはどこに問題があるかも分からないことが多い。もっと言えば、ソフトウェアの問題だけとは限らない。
そんな時、当たりをつけて問題を絞り込み、原因を素早く発見する能力は重要だ。これについては経験を積む以外、いい方法が思いつかない。一緒に問題を調べてくれる、職場の同僚やその分野のエキスパートとのコネクションが、実は一番重要なのかも。
問題に対して最適な解決方法を提示できるスキル
問題の原因は見つけた。さて、どうやって解決しよう。単純なコード修正で終わることも多いが、複数のソリューションがある場合も少なくない。いや、そもそも思い込みから他のソリューションがあることに気がつかないこともあるだろう。
パフォーマンス、コードサイズ、データ量、プラットフォームにおけるバランス、互換性への配慮、などなど様々な条件から複数のソリューションを考え、その中からベストを提案できることは重要なスキルだと思う。とはいえ、全てを一人で決めることがベストではなく、複数の識者の知見をふまえて解決方法を提案できる人の方が優秀かもしれないと、最近は感じている。
とか書いてきたけど
出来てたら、こんなに苦労してないわ!あー、こんなプログラマに私はなりたい(笑)
アメリカで働くことは大賛成だけど、ちょっと考えて欲しいこと
類さんがシリコンバレーでソフトウェアエンジニア職に就くことに関してのエントリーを書いて、それが反響を得ているようなので、その雑感。
海外でエンジニア職に就くことの雑感 – Yoshifumi YAMAGUCHI – Medium
私も短い期間ではあったけどアメリカで働いていたことがあったので、所感など書いてみようかな :)
なお、何十年も前の話なのと、私の観測範囲においてなので、まあ参考程度に読んでいただければ幸いです。
ソフトウェアエンジニアならアメリカに行った方がいいか
という問いに対しては間違いなく行ったほうがいいと答えます。ぼくが言うまでもなく、コンピュータに関する技術は今も昔も多くはアメリカが発祥であり中心で、動きも早いです。日本とは全く違う文化に触れるだけでも、行く価値があると思います。また、アメリカのIT企業の多くはソフトウェア技術者の価値を知っているので、優秀であればとても快適な開発環境が体験できます。最先端でエキサイティングなチャレンジが出来る機会も多いですよ。
もちろん全てがバラ色とは言いません。でもそういったチャレンジが出来るチャンスは人生の中でそれほど多くありません。やりたいという気持ちがあればぜひチャレンジして欲しいな。
ただ、アメリカで長く働くということであれば
ちょっと考えてみて欲しいことがあります。
自分の成果を積極的にアピールしていくバイタリティが必須
アメリカは基本に成果主義であり、自分がしたことの成果は自身でアピールする必要があります。上司が自動的に評価したりはしません。「能ある鷹は爪を隠す」という言葉は忘れましょう。そうしないと「特に成果ないの?じゃあ君はうちとしては要らないね」って話になってしまいます。
あと成果として重要なのは結果です。会社/プロジェクトに対して自分がどんなふうに貢献できたのか、という形でアピールすることが大事。長時間がんばってました!みたいなのはあまり評価されないので注意しましょう。
転職は普通
日本と違ってアメリカでは普通にレイオフされます。長く一つの企業に勤めるより、次々と職場を変わっていく人の方が多いです。逆に言うと、転職については日本よりオープンであり、頻繁に転職したからといって、それがネガティブなイメージになることはありません。
異国の雰囲気に馴染めるか
そしてこれが一番重要なことだと思うのですが、長く暮らしていくにあたり、アメリカの雰囲気に馴染めるかどうか。
ぼくの場合、アメリカに住んでみて、あらためて日本って、なんて住みやすい国なんだろうって思いました。だんだん慣れて来るとは言え、やはり異国の地で暮らすというのはなかなか大変です。東洋人だと露骨にイヤな顔をする人とかもいます。表面的な付き合いをするお友達は多くできるでしょうが、親友を作ることはなかなか難しいです。強烈なホームシックになることもあると思います。
とはいえ、普通に暮らす分にはほとんど問題はありません。「どうしても日本じゃなきゃイヤだ!」って人でない限り、大丈夫でしょう :)
最初に書かれたコードが最も影響力が大きい
最初に書かれたコードって、すごく影響力大きいよね。
もはやファイルのタイムスタンプを確認するまでもないだろう、と私は思った。おそらくは、このシステムは構築の初期、ある程度はまともに作られていたのだ。しかし、そのまともに作ることのできるプログラマは「消えて」しまった。
あとを引き継いだ彼女は「消えた」プログラマほどの技量はなかった。彼女は「消えた」プログラマが残したフレームワークを理解することもできず、ただ、ソースコードを模倣した。
消えたプログラマの残したものは - megamouthの葬列
興味深いですね。
個人的には
プログラミング経験に関係なく、最初に書かれたコードというのは非常に影響力が大きいものであると感じてます。それはそのソフトウェアの設計思想を決定づけるものであり、脈々と受け継がれていくものだからです。優秀なプログラマであるないに関わらず、多くのプログラマは元の設計思想を尊重し、それに合わせたプログラムを書くもの。それがリライトした方が遥かにいい、ヒドいデザインのものでない限りはね :)
そしてプログラムがヒドいものになっていく原因の多くはこの「最初の設計思想」にあることが多いのです。いわゆる要求事項。このプログラムは誰が何のために使うのか。優先すべき性能はどこにあるのか。そして相反する要求があった時、何を基準に機能を決定するのか。もっと言えば、そもそもそのプログラムは必要なのか!?(笑)
そういった設計思想はコードに反映され、伝承されていきます。設計思想が曖昧なプログラムはその後場当たり的な対応がなされ、そのうち使えなくなって最後は捨てられます。書いてて頭痛くなってきた ^^;
そうならないよう精進しますです、はい。
そういえば
カーゴ・カルトという言葉を初めて知りました。盲目的なコピペコード、うんうん、あるよね、そういうの。反面教師にします :)