Raspberry Pi 2に Windows 10がやってきた、IoTが捗るな！
やあやあ。
遂にRaspberry Pi 2に Windows 10がやってきましたよ。
↓
Windows IoT - Set up your Raspberry Pi 2
↓
Windows IoT - Setup your PC for Raspberry Pi 2
↓
いや、もう、これで色々と遊べてしまいますね。
Raspberry Pi 2以外にも遊べるボードがあるようなので、そっちを持ってる人はそっちで遊んでも良いかも知れませんね。
ではでは。
マイクロソフト( Microsoft )が一晩で世界線を書き換えた話
やあやあ。
タイムリーな話だけど、マイクロソフトが一晩でやってくれましたね。
Build 2015は MSのイベントで開発者向けに行っているものです。
そう、このエントリーを書いている間も開催中なんですね。
そろそろ始まるよという話は来ていたのですが、あんまりピンと来ずに一晩寝ていました。すると、朝目が覚めたら世界線が変わっていたんですね。
いつの間に、ダイバージェンス 1% の向こう側へ？
どう変わった？
開発環境の他プラットフォーム展開
Windowsで開発用のエディタと言えばVisual Studioが最初に名前が上がります。誰が何と言おうと、こいつは最強。当然闇も深いが、メリットの方がデカいです。
こいつのコアな機能を取り出して再構成されたと言っても過言ではないエディタとして、プラットフォームの縛りがない状態で公開されました。主にGit、IntelliSense、reference、debugger機能が搭載されており、エディタであると言われていますが、IDEを名乗れるくらいの実装がなされています。
https://code.visualstudio.com/
中身は「Electron + Monaco」だそうですが、最近のトレンドの先端を行ってる感じですね。
on browserなので、どうやら[F12]押下すると開発者ツールが開きます。
そこから眺めるとnative.main.cssにスタイルが記述されているようなので、ここをhackすると、自分だけのオリジナルエディタにお手軽チューンできるのも熱いですね。
また、Macでこれを使うとUnityが日本語環境で書けるようになるとかなんとか。補完も恐ろしく速いらしいので。救世主となりえるのか？
Visual StudioでObjective-Cがコンパイル可能になった
知って直ぐに出た言葉が、「……正気か？」でした。
どうやら正気のようです。
実際には、Android用のアプリやiPhone用のアプリをWindows上に持ってきて、チョロッと直してWindows用にbuild出来る変態SDKの提供だと(語弊をはらみつつ)理解すればよいようです。
実際には、その通りではないですが、まあ夢がある話ですよね。うん。
Androidの方はほぼストレートで持ってこれるそうなので、Android AppとWin Appの同時開発はWindowsで、iOSはMacでとなっていくんですかね。MacユーザーはbootcampにWindowsを入れるんでしょうけどね。
この流れ、Windows Phoneがnew Windows ( Windows 10 )ベースで出てきて、既存のプラットフォームを食い漁りに来るという宣戦布告なのだろうか？
Huge news: Windows 10 can run reworked Android and iOS apps | The Verge
さようならInternet Explorer ( IE )
IEと別れを告げる日が来たようです。つい最近、Trident engineに泣かされたばかりの私ですが、EdgeHTML engineを搭載したMicrosoft Edge ( 開発コード：Spartan )がWindows 10では実装されるようです。今後は、IEではなくMEということですね？
で、このEdge、FirefoxとChromeの良い所を多分に吸収し、果てにはそれらプラットフォームの拡張機能をちょっと直すだけで取り込めるようにしようとしているようです。
Microsoft's Edge browser can steal Chrome and Firefox extensions | The Verge
先のAndroid / iOS Appの取り込みと続き、なりふり構わぬ本気のMSが見え隠れしていますね。
現実拡張でWindows 10が世界に溢れ出す
Windows 10 apps in HoloLens look amazing and completely ridiculous | The Verge
いやもう、何が何やらですね。
一気にここまで来るとか、恐ろしい話です。
今までのヘッドマウントディスプレイとは全く異なる何かですね、これは。
MSは今までのOSを作っている会社とは違う世界へ踏み出したようです。
前からそういう事に投資をしている会社ではありましたが、ここまで大きく出たのはここ最近ではなかったんじゃないですかね。
賛否両論あると思いますが、私は好意的に受け止めたいと思います。
そういえば、build 2015ってまだ開催中なんですよね。明日は何があるんだろうか。
関数型とオブジェクト指向の話
やあやあ。
この記事はポエムだから肩の力を抜いて欲しい。
最近話題の関数型
最近巷で関数型ポエムの話をよく聞いたね。
あのポエムが良いか悪いかの論争はこの場は論じないでおこうと思うけど、そもそも関数型ってなんなんだろうね。
関数型プログラミングについて書いてある本を読むと、先ず最初に目に飛び込んでくるのが、「数学でいう『関数』と同様に、一意の値を与えると、常に同じ答えが返ってくる、副作用がないもの」という表現である。
語り始めると宗教論争が生じるし、この表現でもまだ突っ込みどころはあると思うので深入りはしまいと考えているが、要はそういう表現型ばかりを使ってプログラミングを書いていくと、副作用を排して手堅いコードになっていきますよねと言う事らしいのだ。
関数型の発想が与えるオブジェクト指向への影響
関数型は、ある種の思想であると、私はここ数年捉えるようにしている。
これも色々宗教論争を呼びそうではあるが、聖書に書かれた教えの解釈は宗派によりけりなのである程度は目をつぶって頂きたい。
オブジェクト指向でプログラミングを書いているとよく陥るのが、プログラムが実行中に「状態」を持ってしまい、それによって「タイミング」が生じ、時によって「結果が異なる」挙動を示す場合がある。
これを関数型の教義では「副作用がある」と表現するらしいのだが、そんな表現を知らなくともよくある経験だと思う。そこでよく使う方法が、条件分けや例外処理である。私はこれらを、「副作用を分類している」のだと解釈している。
私は今までの仕事柄、副作用を生む処理を記述すると、不具合によっては私の睡眠時間や空実が失われていくという「副作用」を齎すと言う事を知っていたので、関数型という思想に触れる前から、関数的に処理を書こうと試行錯誤をしていた経験がある。
ある日、Scalaと出会い、その後Haskellと出会った。
正直に告白すると、そのどちらの言語も満足に書ける自信はないのだが、それらの一片に触れ、考え方を覗き見たという経験は非常に役に立ったと思っている。
関数的に書くという意識を持つだけで、純粋な関数言語ではない他のオブジェクト指向言語においても、１メソッドを起こすだけにしてもよく考えるようになった。
真に副作用を排する事は極めて困難であっても、「副作用はこの場合何を齎すのだろうか」と考えるだけでも、やはり関数型言語に学ぶところは多いのである。
平々凡 々なオブジェクト指向エンジニアが
関数型とどのように向かい合うべきか
自身の業務や現実と向き合ったうえで、学んだ分だけ可能な範囲で取り入れていけばよい「教義」と捉えると幸せになれるんじゃないかなと思います。
関数型の信徒になって、その世界に閉じこもりたいと思うようになれば、そういう人はそれを専門に使っている世界へ進むと幸せになると思います。
ファン程度であれば、教義に倣う程度でにわか関数型エッセンシャル使いを名乗ると幸せなんじゃないのかな。
真剣に学ぼうと思うのであれば、先人の教義に従い、古の専門書から手を伸ばすのが吉であると、私は思います。
ではでは。
CSSでセンター寄せはどう書き分けるべきか
やあやあ。
HTML5ではcenterタグが非推奨になっているらしいね。
と言う事で、要素の中央寄せをCSSでする方法についてのメモを残しておくよ。
- marginプロパティ
- margin:auto
- margin-left:auto + margin-right:auto
- text-alignプロパティ
- text-align:center
実際は上記のようなプロパティをCSSから指定することになる。
margin系とtext-align系の大きな違いは何であろうか。
margin系で中央寄せをする場合
margin系は、指定されたオブジェクトを寄せます。
その場合、オブジェクトの中身（ここでは文字列）は左詰めのままの解釈を受ける。
<style>
#margin_test{
width: 200px;
margin: auto;
background-color: #808080;
}
</style>
<div id="margin_test">てすとてすと</div>
てすとてすと
<style>
#margin-left_test{
width: 200px;
margin-left: auto;
background-color: #808080;
}
</style>
<div id="margin-left_test">てすとてすと</div>
てすとてすと
<style>
#margin-right_test{
width: 200px;
margin-right: auto;
background-color: #808080;
}
</style>
<div id="margin-right_test">てすとてすと</div>
てすとてすと
<style>
#margin_LRmix_test{
width: 200px;
margin-right: auto;
margin-left: auto;
background-color: #808080;
}
</style>
<div id="margin_LRmix_test">てすとてすと</div>
てすとてすと
text-align系で中央寄せをする場合
text-align系で中央寄せをする場合、オブジェクトはそのオブジェクトの指定属性のまま、その中身（ここでは文字列）が中央寄せの解釈を受ける。
<style>
#text-align_test{
width: 200px;
text-align: center;
background-color: #808080;
}
</style>
<div id="text-align_test ">てすとてすと</div>
てすとてすと
どっちを使うべきか
中央寄せしたいモノで決めよう
但し、margin-leftとmargin-rightの合わせ技で中央揃えをする場合、古いIEでは適切に解釈されない可能性がある事を知っていないと罠に嵌る。
buttonであるべきかinputであるべきか、それが問題が
やあやあ。
最近HTMLを復習してるよ。
で、その時思ったことを適当にメモしてみようと思う。
今回のお題は
「ボタンを作成するとき、button要素であるべきか、input要素であるべきか」
| inputタグ | buttonタグ |
私が昔、ゴリゴリとHTMLを手書きしてた頃は、ボタンと言えばinputタグで書くのがセオリーだった気がしています。最近は、buttonタグを使うようにしている文献をよく見る気がします。
(inputタグでボタンを作るというセンスはHTML4以前の感覚なので、今となってはかなり古いものであるという認識です。私が最も活発に手書きしていた時代は、ページデザインはtableタグで行うのが基本だった時代ですので、かなり古い話ですね。その後、デザインはdivタグにidを振りまくって、CSSでムギュっとするのが基本の時代が来ましたが、最近はHTML5でもっとタグの種類が増えて、文章構造がさらに細分化された認識を受けます)
実挙動について
実挙動はどちらも同じように振る舞っていると、私は感じています。
ただ、IE7以前はbuttonタグの解釈にバグがあったそうなので、レガシーなシステムでは考えた方が良いのかも知れません。
＜IE7のバグは以下のようなものでした＞ <button type="submit" name="buttonName" value="hoge">foo</button>
このタグで、通常はPOSTの値がbuttonName=hogeとされるべきところが、
buttonName=fooとされてしまっていたようです。
しょっぱいですね
もうIE7以前は古いブラウザですし、何処かで割り切ってしまっても良い気はします。ただ、MSはIE7(2006年)、IE8(2009年)のサポートを2016年1月までするつもりなので、「まだ気が早いんじゃないか？」と言われる事案も少なくない気がしてしまいますね。
一般向けにオープンするwebサービスなのであれば、今さらinputタグにしがみつく必要はないんじゃないかなという気がします。
皆さんは、どう捉えてます？
TypeScriptの開発環境をVisualStudio 2013上に構築する為のメモ
やあやあ。
TypeScriptの良い感じのIDEを求めて、VisualStudio 2013上に開発環境をサクッと作ってみるよ。
VisualStudio 2013がインストールされている前提で話を進めるよ。
インストール出来ていない人は、以下を見てインストールしておいてね。
最初にTypeScriptの拡張を入れます。
以下から取得します。
2015.03.16現在は、downloadのToolsの所にリンクが張られているので、ここからインストーラを入手。
次に、インストーラを実行。
規約に問題がなければ同意をし、INSTALL
しばし待つ
完了。closeを押せば閉じます。
これで、VisualStudioで新しいプロジェクトを作成するときに、TypeScriptのプロジェクトが選択できるようになっています。
VisualStudioのサジェスト機能が結構頑張ってる感じなので、使えるならこの開発環境でも良いんじゃないかなと思います。
ではでは。
本当に効果的なKPT (Keep/Problem/Try) とは
やあやあ。 KPT、してますか？
やってる？ なるほど。で、本当に効果的なKPT、やれてますか？
悪循環を生むKPTのやり方
- K：明日もがんばります
- P：私が全部悪いんです。すみません
- T：今日出来なかったことは明日やります
もしこんなKPTを繰り返していると、自尊心を過剰に侵害し、個人のモチベーションが低下してしまいます。メンバや部下を潰すことが目的であればそれでも構いませんが、鏡に向かって「お前は愚か者のクズだ」と言わせ続けるような行為は、決して良い結果を生み出しません。
（私が良いと考える）効果的なKPTのやりかた
- K：このタームで出した成果を評価し、それを継続する賞賛のKeep
- P：個人ではどうにもならない環境やプロセスに関するProblemを提起
- T：Kに対する追加アプローチ、または新たなる挑戦/改善としてのTry
私は、このようなKPTの運用が良い効果を生むと言う事を経験しています。
分量としては、K：P：T＝2：1：1程度で捉えると良いと考えています。
また、自分一人でやらずに他人と一緒にやると良いです。
互いに言語化するもの恥ずかしいようなレベルでKを出し合いましょう。
今出来ていることは、それだけで素晴らしい事です。続けるに値するのであれば、それは賞賛されるべきです。
貴方は誇りを持ってそこに立っていてもよいのです。
但し、驕ってはいけません。
あくまでその自尊心は、貴方がエンジニアであり続ける為に持ち続けるべきです。
個人の技能問題や、知識・解釈・理解に関する事象は、Pに書いてはいけません。
それは、貴方の将来的な「課題」であり、「取り組むべき改善」です。
書くのであればTに書きましょう。
Pは、貴方の力でどうしようもない「本当の問題」を書き上げるべきです。
そして、貴方はそのPを再認識し、乗り越えなければいけないのであれば周りに助けを求めましょう。
貴方は一人では生きていけない。であれば、誰かと生きていく方法を模索するべきだ。
Tには「取り組むべき課題」や、「改善すべき事実」を書きましょう。
あくまで貴方の持ちうるリソースで戦える粒度で書くことが重要です。
漠然と書くことは避けた方が良いです。
Tは貴方にとっての、近未来に到達したいビジョンとして目標に掲げなければいけません。
貴方がそこに向かって死ぬ気で走る事になるのです。
到達点が見えないような道を、貴方は走り続ける事は出来ないでしょう。
短距離で構いません。貴方が全力で駆け抜ける事が出来る粒度で目標を定めましょう。
え？ 意識高い系エントリで臭いって？
まあ、たまには良いじゃない。
もっと、自信を持って生きようよ。
