はてなブックマーク

スーパーバイザーで入ったプロジェクトがPythonメインだったため、これまでずっと食わず嫌いだったPythonを速修しています。初めてPythonの名を知ったのは間違いなく10年以上前、もしかしたら15年ぐらいかもと思いますが、オフサイドルールと呼ばれる改行とインデントでブロック認識させる書き方がなんか馴染めなくてHello World以前に避けてました（たとえばYAMLよりJSONの方が好き）。時が過ぎ、GoogleがAppEngineをPython版でリリースした時も遅れてJava版も出たし、クラウドでの機械学習等についてはその機運が高まっている時にそもそも自分が手を動かすところにいなかった。つまりこれまでは避けてもなんの支障もなかった。 しかし、今やAmazonやGoogleやその他のクラウドでもPythonが第一言語なのかなというぐらいにどこでも対応されているのでやって無駄はなかろ

Angularが教えてくれた。 TypeScriptの学びの中で、他のライブラリの型情報をどう手に入れるかは説明されているのだけど、ライブラリとしてどのように型情報を提供するのかはあまり説明されていない。ECMAScriptで書かれたライブラリに後付けでindex.d.tsだけ書かれ、それが@typesに登録されているというのがよくあるケースだけども、そもそもTypeScriptで書いてる場合はどうしたらよいのか。まさか二度手間にチマチマ書きおろすわけもなかろうと調べてるうちに、事例としてとてつもなく巨大なのがあるのを思い出しました。Angularです。たぶんこいつはTypeScriptで書かれた世界最大のソフトウェアなんじゃないかなと思います。実際に、Angularはチマチマindex.d.tsを書くなんてことはしていなく、以下のようなindex.tsを用意しています。 // index

一昨日、昨日の続きです。 react-routerをv4へマイグレーションすると同時に、react-router-reduxもv5に上げます。こちらはまだアルファ版ということですが、十分に機能するしとてもシンプルなためにコード読んですぐ分かる内容ですから、危険視するほどではないと思います。 $ npm install --save react-router-redux@next $ npm install --save history 5.0.0-alpha.6でした。ここ1ヶ月ぐらいはコードが動いていないし、まあほぼ完成なのでしょう。 // Root.jsx import React from 'react'; import injectTapEventPlugin from 'react-tap-event-plugin'; import { createBrowserHistory

TypeScriptのReactアプリを作るに際し、一番シンプルなのはWebpack DevServerで実行だけするというものかなと思います。NodeとYarnはすでに入ってること前提で、あとはテキストエディタ＆WEBブラウザだけでOK。 $ mkdir TsReact $ cd TsReact $ yarn init $ yarn add react react-dom $ yarn add @types/react @types/react-dom -D $ yarn add typescript webpack webpack-dev-server path awesome-typescript-loader -D まずターミナルからプロジェクトの基盤を作ります。フォルダ作ってYarnでやるべきことをやる。reactとwebpack関係はES6のプロジェクトと一緒ですが、Babel

テスト環境をJasmineからJestに入れ替えましたので、カバレッジを上げるためおよびTDD的にもこちらの活用を行っていきたいと思います。一年ぐらい、いや二年？、目を離した間にモック機能がかなり成熟していました。 そのまえにeslint react/jsx-boolean-value 細かい話として、ずっとJSXでBoolean値のプロパティに対してリテラルでtrue / falseを書くとEslintに怒られることに理不尽を感じてましたが、理由と対応を目にして納得しました。 理由：https://facebook.github.io/react/docs/jsx-in-depth.html#booleans-null-and-undefined-are-ignored JSXでBooleanリテラルは出力されないから。そのため思惑違いのコードを書かせないためにBooleanリテラルをJ

reactのルーティング機能？というかテンプレートシステムというか？にreact-routerがあります。リクエストパスに応じて画面構成要素を組み立てるのでreact-routerを使ってアプリケーションを作ると当然URLと画面は同期することができます。URLを直打ちしてもコードでURL遷移させても、適切な画面に切り替わるように作れるのです。 reduxはその際にどうかというと、URLや画面構成といったものについて素で働きかけるものではないので、URLが変化してもreduxのステートマシンにはその情報は反映されません。そこにはもう一つ上乗せするものが必要です。いくつか同じ守備領域のライブラリがあるようですが、わたしはここのところしばらく、中でも主流感のあるreact-router-reduxを用いています。 GitHub - reactjs/react-router-redux: Ruth

reactアプリケーション開発においてコンポーネントに引数として渡されるpropsと、スコープの大きな実行時変数としてのcontextに加えて、もっぱらコンポーネント内部の状態管理としてのstateをあれこれ操作するのがデータフローの基本だったのですが、ここ一年ぐらいで様子が一気に変わってしまいました。reactの普及と対象とするアプリケーション規模が大きくなることによる複雑性の課題に応えてFluxが提唱され、その実装バリエーションで淘汰を経たreduxの登場です。それまで標準であったコンポーネントstate管理によって多数散在してしまった複数ステートマシンの連携を否定して、アプリケーションレベルで一つの大きなステートマシンをつくってpropsを通じてのみコンポーネントツリーに反映させるという。たくさんあるものをn:nに対応させていくってのは複雑を、常に抽象から具体へ1:nになる流れに修正

Mac環境を汚さないように壊れてよい仮想なMacを作ります。どうせいまなら出たばかりのSierraで。Mac on MacはVMWareをつかうと超簡単と聞きますが、追加無償でも十分！VirtualBoxで作ります。ホストはEl Capitan。トータルで2時間半ぐらいかかりましたが、ほとんどがSierraのダウンロードと、インストールの待ち時間であり、作業は正味30分もかからなかったと思います。 Sierraのイメージを手にいれる（実績1時間以上かかった） App Storeで「macOS Sierra」の「ダウンロード」ボタンを押してダウンロード開始。回線状態にもよるでしょうが大変時間がかかります（自宅は超高速なんですが、オフィスの回線は遅い）。ダウンロード完了したらインストーラーが起動するのをキャンセルします。/Applicationに、「Install OS X Sierra.ap

（承前：昨日の追記） react-mixin(https://github.com/brigand/react-mixin)でES6のclass構文を試してみました。書いてから気がついたのは、短時間で試したぐらいの中ではちょっとコード書き直すだけでどんどん筋が悪い体裁になっていくので、時期尚早というか私にはまだ無理ゲー。もうチョイ調査が必要。 propTypesの宣言がclassブロック外に記述 getDefaultPropsの対応がclassブロック外に記述 mixinの対応でreact-mixinを使ってみたけど。。。 このためにreact-mixinのrequire、まあこれは些細なこと classブロック外でのmixin作業 MixinメソッドがAutoBindingが無いために各所でbind(this)を書かなくちゃいけない。これがヘビー mixinはReactコンポーネントじゃ

数日、バタバタと調査しては考えが変わる毎日ですが、ES6-classでReactアプリを書く前提が整ってきました。 classボディ外に、propTypes/contextTypes/childContextTypesを書くのも、そういうものと思えばまあいいか MixinはAOP的なラッパーコンポーネントを生成する関数で書く。移行もすでにES6記法で書いてたのでさほど面倒ではない contextはES6-classでも大丈夫だった BabelでES5へトランスパイルし、Browserifyでクライアント用はまとめる。 テスト周りがちょっと試行不十分だけど、Jest&Babel&Gulpで簡単なものはOK おそらく最後にして最大の課題はIDEのことです。コード的にはOKでもIDEがエラーや警告だしたり、逆に出すべきところで沈黙してたりすると書き方云々以上にストレスですから。今、私はWebSt

Material Designを実現するReactコンポーネントセットであるmaterial-uiは有用な上で、ソースを読んでも大変参考になるものが多くあります。中でもDatePickerのコードはReactでの動作エフェクトの作り方の他、コンポーネントを組み合わせてコンポーネントを作るというReactの基本的なことまで、多様なテクニックの良質なサンプルともなってます。しかしそんなmaterial-uiもL10nについては手が付いてません（v0.14.2現在）。 https://github.com/callemall/material-ui/blob/v0.14.2/src/utils/date-time.js warning(locale === 'en-US', 'Wrong usage of DateTimeFormat. The ' + locale + ' locale is

悪意ある攻撃への対策として、Responseのヘッダから'x-powered-by'を削ると良いという。 Expressでは何もしなければ、サーバ実装を示すこのヘッダ値に'Express'と正直に返してしまいます。そうなると悪い人が「そうかNodeでExpress使ってるのね」とすぐわかってしまうので攻撃前の一手間が省かれてしまうという。いや、しかし、Node+Expressは一定以上使われてるメジャーなプラットフォームだと思うので悪意ある人の前では無駄な努力だとは思うけど...とりあえずおまじないとしてやっておく方がより良いということでしょう。 var app = express(); app.disable('x-powered-by'); これだけ。 そういえば、Node5.1.0にアップデートされていました。$sudo n stableではまだ対応されてなかったので$sudo n

JavaScriptを書き、Reactに触れるにあたって、エディタをどうしようかと一回りしました。元々Javaな人なんでEclipseなどの統合開発環境でがっちりサポートされてきた身としてはテキストエディタだけでっていうのは不安です。不安なんで一年前には速攻でJetBrainsのWebStorm 7を買いましたね。改めて調べるとJetBrainsにおけるメジャーバージョンというのは相当軽い意味のようで、バージョン11が出ようかというところでした。 一方で、先月MDLを書いてた時には横にいた新井さんから教わったAdobe Bracketsを試してました。Bracketsは無料なので気楽ですし、HTML＆CSS書くのにはいいですねー。ボタンポチッと押すだけでエディタと連携したデバッグ用Chromeブラウザを立ち上げるのが便利。コードをちょっと書き換えるだけでビュー更新が即時されるのが素敵。ただ

ECMAScript6でクライアント側を書いてますが、極小のHello Worldレベルから一歩進むだけで壁が。JavaScriptの発展の歴史の中で大きなアプリケーションを作るためのパッケージ参照機構が様々用意されてたみたいですが、そこにまた大きな曲がり角が出てきちゃってた。 原始時代より長らくHTML上でscriptタグのsrc属性にファイル名を指定することで読み込むという参照方法のみだった。 サーバ側でもJavaScript使おうよとNetscapeを始め何度か繰り返されては散り、しばらく忘れ去られていた太古の試みは、Node.jsの登場でルネッサンス。 Node.jsがプラットフォームとして実装したrequireでnpm管理されたパッケージ構成を参照させたのを模して、独自にライブラリレベルでrequireをクライアント側へ導入する文化が花開く 産業革命。ES6でimport/exp

UIViewの周りの枠線は、プロパティ一発とかいうことは無く、ちょっと書くみたい。layerをいじるのは前のUIImageを丸くしたところと一緒の考え方ですが、こちらの色指定がUIColorではなくCGColorというCoreGraphics.Frameworkのものでした。ただしサラッと書くとUIColor#CGColorで変換できるので名前解決のためのimportは不要です。 import UIKit //import CoreGraphics class ViewController: UIViewController { @IBOutlet weak var targetView: UIView! override func viewDidLoad() { super.viewDidLoad() targetView.layer.borderColor = UIColor.redC

01: @Test 02: public void testPipe() throws Exception { 03: PipedOutputStream out = new PipedOutputStream(); 04: PipedInputStream in = new PipedInputStream(out); 05: out.write("0123456789".getBytes()); 06: // out.close(); 07: while(true) { 08: byte[] buffer = new byte[8]; 09: int len = in.read(buffer, 0, buffer.length); 10: if(len <= 0) { 11: break; 12: } 13: System.out.write(buffer, 0, len); 14:

Robolectricで書いたお試しコードですが、RetrofitでHTMLのスクレイピングをしてみました。HTMLのパーサーはJsoupを用いています。手元の実行環境はAndroid API16とRobolectric 2.4ですけど、サンプルは画面が無いのでほとんどバージョン関係なく動くと思う。 @RunWith(RobolectricTestRunner.class) public class RetrofitUsage { @Before public void setUp() throws Exception { // ./gradlew -i test を実行すると、Androidログが標準出力に書きだされる ShadowLog.stream = System.out; } @Test public void getJsoupDocuments() { RestAdapter

GradleでJUnit4+Robolectricをターミナルから動かしてます（仕事じゃなくって現実逃避ですけど）。IDEからはapp.imlを直接いじるという面倒なセットアップが無いと動きませんので、世の中の進歩をまつことにしてます。 今日、突然その環境が動かなくなりました。現象としては./gradlew testを実行すると、java.lang.NoSuchMethodErrorでストップ。 java.lang.NoSuchMethodError: org.objectweb.asm.MethodVisitor.visitMethodInsn(ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Z)V at org.objectweb.asm.commons.GeneratorAdapter.invokeInsn(Unknown

HTMLをクライアント側でちょっとパースする要件にてiOSで使えるHTMLパーサを調べると、いくつかあるのですが、HTMLReaderというのがたまたま目につきました。 // Bridge-Headerにて、HTMLDocument.hとHTMLSelector.hをインクルードしてる import UIKit import Alamofire class ViewController: UIViewController { @IBOutlet weak var textView: UITextView! override func viewDidLoad() { super.viewDidLoad() let req = request(.GET, "http://number.bunshun.jp/articles/-/821939") req.responseString { (_,

このAlamofireは、iOS界ではメジャーと聞くAFNetworkなるライブラリを作ってた人がSwiftで書き下ろした、新進気鋭なるものということです。AFNetworkが世に出たらしい時期は私にとって金勘定に専念していた技術的ブランク時期だったためにまったく知らなんだが、技術力高く信頼感あるという雰囲気はちょっと見るだけで伝わって来る。その発展系？のこれはたった一つの.swiftファイルでたしかに綺麗なコードです。extensionで省力かつコードブロックを見通し良く書くのは参考になります。利用においてちょっと面倒なのはFrameworkにコンパイルされて動的バインドする仕掛けなので、プロジェクト設定に一手間必要な事でしょうか。たぶん.swiftファイルをプロジェクトに突っ込むだけでOKっぽい気もするけど。。。今回は言われる通りにちゃんと設定しました。 追記：Alamofire.sw

SwiftでiOSアプリ書くのはすっきりとした文法で快適なのですが、凝ってはいるけど定番な動きを実現したいときには誰かが作ってくれた部品を使いたくなります。Githubにもそれはそれは多くのiOS向けのOSSがありますし、大抵はMITライセンスなので仕事でも使い易い。しかしこれらは現在ほとんど全てがSwiftではなくObjective-Cソースコードで提供されています。そのうちSwiftのものも増えてくるでしょうけど今はObjective-Cだけ。 SwiftからObjective-Cを使おうとしたとき、承前としてまず読むべきなのは以下のドキュメント。私はXCodeを開いたMBPの傍ら、iPad miniのiBookに落として読んでます。 一瞬ハマりました。いきなりこのドキュメントにあるダイアログ（「Would you like to configure an Objective-C br

副題「コードによるインフラ構成の自動化」にしびれる。 Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) 作者: 吉羽龍太郎,安藤祐介,伊藤直也,菅井祐太朗,並河祐貴出版社/メーカー: 技術評論社発売日: 2014/05/22メディア: 単行本（ソフトカバー）この商品を含むブログ (5件) を見る 基本的な主戦場をNGINXモジュールとNode.jsとPostgreSQL/PLV8のストアドプロシージャに求めてるのですが、まずそれ動かすための環境は必要なわけです。これまではOS Xの上に直に構築してごまかしてたけど環境ごちゃごちゃしてくるしどうしたものか。常にこのへんは先送りしていたのは私がインフラ方面にはスキル積んでこなかったからですね。昔のクラサバからJava製WEBアプリの経験だし、コンパイラ言語ばっかりだからJavaScriptとかでもこれ

Node.jsはエコシステムが発達していて、コアライブラリだけでなく、サードパーティがたくさん有用な拡張モジュールを提供してくれています。また、自前で書くコードも一つのJSファイルだけで書くのではなく、見通しも良いように、再利用可能なように、機能単位毎にモジュールにまとめて作って行くべきでしょう。その際、ライブラリ的なモジュールでは具体的に実行時例外の処理をすべきではないのが一般的だと思います。例外処理をおこなって例外握りつぶしちゃうと問題が内部で起きている事をアプリケーションレベルできちんと把握できなくなっちゃう。 Node.jsのライブラリ作法としては、例外をそのままthrowするのとは別に、下記の書き方があります（以下、冗長なのでモジュール分割しないで書いてますが...）。 var events = require('events'); var emitter = new event

テスタブルJavaScript 作者: Mark Ethan Trostler,牧野聡出版社/メーカー: オライリージャパン発売日: 2013/09/21メディア: 大型本この商品を含むブログ (1件) を見る 先に読んでるもので渋滞していたので持ち歩きだけでしたが、今朝より読み始めました。オライリーに限らずJavaScript書籍は、言語汎用に取り扱う場合でも大概がWEBブラウザ動作前提での説明になりがちで、それはこれまでの歴史や現在の使われ方に即せば当然なのですが、この本はNode.jsが前提な説明の書き方のためにWEBブラウザ特有？の雑音が少なくて読みやすいです（まだ読み始めですが）。一方で内容はもちろんNode.jsに特化したものではなくJavaScript開発一般におけるテストとは何か、どうしたらいいのかという論旨で、たいへん高度な内容です。具体的なテストツールの説明ではなく、テ

iPhone4を手に入れました。開発テスト環境として既存のiPhone3GSもしばらく生かしておく必要があったため、新規でiPhone4を購入しました。私は今後4を常用し、3GSは開発テスト用に必要な期間が終わったら回線契約を解除します。抜け殻の3GSはサイオスの営業部長が3Gユーザーで、3GSを欲しがってたので横流れて行く予定です。 電話番号を変えたくないので4と3GSのSIMをスワップしたいのですが、課題発生。既によく知られているとおり、iPhone3GとiPhone3GSではSIMの規格が同一で簡単に抜き挿ししてスワップ完了でも、iPhone4ではマイクロSIMが採用されたために物理的に大きさが変わりそのままでは3GSのSIMが挿さりません。世の中には大きな旧来のSIMをカッターやハサミで切って挿すという荒業も紹介されていますが、常識的な社会人として、そこにはどうにもリスクを感じます

http://songofcloud.gluegent.com/2010/05/java1.html ご覧になっていただけたでしょうか？グルージェントのBLOGの方に、Javaコードを採点するシステムを組み込んでもらいました。これは過年度より細々やってもらっていた新しいJavaコンパイラ「Irenka」の応用例として、e-learnigっぽい見せ方をしたものです。問題に解答する形でコードを書くと、GAEに配置した問題サーバおよびその背後の採点Agent群によって添削してくれます。デモなんで添削コメントはそっけないですが、採点Agentへ差し込む問題リソースを練りこめばいくらでもユーザーエクスペリエンスは向上する余地があります。また、高負荷になっても採点Agentをたくさんに増やせば理論上は無限に近いスケールアウトをするようにしています。アーキテクチャは面白く、私は「元気玉」と呼んでいます。