PNG にはメタデータを保存するチャンクがある。Python からも簡単に読み書き可能なので、ここに prompt を保存しておくと、あとから参照したいときに便利になる img が PIL の Image だとして、save を呼びだしているとこに pnginfo というのを足してあげる。 from PIL.PngImagePlugin import PngInfo # ... metadata = PngInfo() metadata.add_text("prompt", "foo bar baz") img.save("./outputs/0.png", pnginfo=metadata) 読み出し #!/usr/bin/env python import sys from PIL import Image from PIL.PngImagePlugin import PngInfo
HS105 を買ってみた。中にリレーが入っていて Wi-Fi 経由でオン・オフできるというもの。 値段的には3000円ぐらいで買ったので、まぁこのぐらいだろうという気がする。まともな24時間タイマースイッチと同じぐらいの値段と考えると、買える値段。定価だとちょっと高いなと感じる。 アプリからのオン/オフは結構はやい。リレーの動作音 (カチ) がするので、リレーの動作音が好きな人(自分)には嬉しい。 最大電流が14Aまでだけど、14A限界まで連続して使うような負荷には使わないほうが良さそう。今のところエアコンと連動させたいサーキュレータに使っている。 うちでは他に使えそうな機器があんまりないかな。冬になったらホットカーペットに使うのが便利かも。あとはいざってときに強制的に再起動したい機器につけとくと遠隔で再起動できて良いかもしれない。 Google Home から制御 デバイスは TP-Li
既存のインターフェイスを妨げない 今まで使えるものはそのままにする。アクチュエーターが既存の操作の邪魔をしないこと 「生活」に持ちこむ学習コストを最小限にする。少しずつ便利にする 必要ないならインターフェイスを変えない 今までと似た体験にする。アフォーダンス (形の意味) を変えない 必要がないならインターフェイスを追加しない (ゼロクリックを動くことを目指す) それ手でやればよくない？ 意味がないことを自動化しても意味がない。家族にも便利であること インターフェイスの罠としては「定期的に音声で通知する」みたいなのは意外と使えない。というのも、人間だんだん慣れてきて、同じ音が定期的に鳴っていても聞こえなくなるため。視覚に訴えるほうがいいのかも？ トップ tech おうちハックで必要なこと
家庭内 Slack とかやってる人は結構いますね。羨しいなと思ってましたが、うちの妻は英語と技術的なことがさっぱりわからないので Slack ですら敷居が高く、インストールしたり説明 (チャンネルの概念とか、それがどういうノリで機能するかとか……) するのもめんどうなので家庭内チャットボットみたいなのは全くやる気がしなかったわけですね。Slack って英語だったけ?と思うかもしれませんね。普通気にもとめないでしょうが英語なんです。ウェブ系IT企業のノリって一般的じゃないんですよ、知っていましたか。 それはともかく、最近 IFTTT の通知先に LINE が増えたり、LINE への通知の API ができたりしたので、家庭内チャットでワンチャンアルデと思ってちょっと頑張って試すことにしました。 つくった IFTTT レシピ エリアを抜けたらグループへ通知 帰宅しはじめを自動的に伝えるようにとい
ここ数ヶ月ぐらいキーボードを作っていた。そのためにいろいろ yak-shaving としかいいようがないことも多々していた。 いろいろ書くことが多いので、細かい設計などについては別途エントリを分ける。 コンセンプトとキーレイアウトおよび技術仕様の決定 回路設計とアートワーク・実際の製作 ファームウェアの実装 あたりをそれぞれ別途詳細なエントリを書く。だいたいの人は細かいことはどうでもいいと思うので、概要のみこのエントリにまとめる。 コンセプトや特長 UNIX ベースのキーレイアウト (というかHHKBをベース) とし、違和感なしに分割キーボードとする。 キー配列 UNIX キーボードを2分割した形を基本にする。つまり HHKB とほぼ同じで、Ctrl キーはAの左、ESC は 1 の左など。 矢印キーはどうしても欲しい (HHKB への大きな不満のひとつ) F1〜F12キーもできれば欲しい
プログラミングが分かってる相手に気軽に挙動について訊ける機会なんてありませんね。仕事なら同僚に訊けばいいと思いますけど、同僚が暇とは限りませんし、学生ならそういった相手がいないことが普通ではないでしょうか。 ということで、独りで言語を学ぶ方法について考えます。 作りたいものを決める 大変重要なところです。どの言語でも書けて、どの言語も多少の個性が出て、そこそこ簡単なものがいいですね。 ぼくの場合は blosxom という「テキストファイルをスキャンしてHTMLにするだけのブログツール」なんですが、まぁなんでもいいと思います。ぼくはウェブエンジニアなので、ブラウザに何か表示がでるとそれだけで嬉しいというところがあります。 リファレンスをひけるようにする どの言語も必ずどこかに言語リファレンスがあります。必ず公式のものを一式見れる状態にします。そしてできれば Chemr とか Dash みたい
今までのページャは良くある ?page=2 みたいな形式でした。これは内部的には offset / limit を使う SQL になります。 変更したページャは /.page/20160509/3 という形式です。20160509 が表示するページ番号、3 がそのページに表示する最大の数です。ページ番号はトップページからのページの場合、日付になっており、内部的には日付ベースの where 句になります。3 は limit です。 これらによって、サーバ側のエントリ表示数のデフォルト設定によらず、URLによって決まる内容が生成されます。よって キャッシュ無効化の負荷が減る 古い形式だと ?page=xxx なキャッシュは1つエントリが増えるたびに全て無効にしないといけません 古いページを表示したときの負荷が減る offset / limit はそのページに至るまでの全てのエントリをソートして
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
HTTP2 化に伴なって、サイト全体の最適化を行ないました 依存の整理 もはや jQuery なしでも簡単に書けそうなスクリプト部分から jQuery 依存を抜きました。また、JSDeferred を Promise で置き換えました。 script 要素の async / defer script 要素については必要に応じて async や defer をつけるようにし、基本的に外部スクリプトでブロックする可能性を排除しました。 async は script 要素同士で独立している場合無条件につけられます (非シーケンシャル)。defer はページのDOMが構築されたあとに実行されるように遅延されます (シーケンシャル) defer は DOMContentLoaded 直前にまとめて呼ばれるようです。 外部ライブラリを自分でホスト 外部ライブラリをCDN経由でロードしている部分がありま
そろそろ HTTPS でしか使えない新機能なんかを使いたくなるので、すこしずつノウハウを溜めようという気持ちはあります。 localhost 自己証明書 ググって出てくるコマンドだと対話的インターフェイスでどうでもいい情報を入力する必要があってダルいので一発で自己証明書つくれるようにします。 #!/bin/sh cd dev CN=localhost openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr -subj "/C=JP/ST=Kyoto/L=Kyoto/O=Example/CN=$CN" openssl x509 -req -days 1024 -in server.csr -signkey server.key -out server.crt rm server.
細い回線で Chrome のダウンローダだとうまくレジュームできないことが多々あって厳しい。キャンセルするとダウンロード途中のファイルが消えたりするし (余計なお世話だ)、大きなファイルはダウンロードしにくい。 ということで、curl でダウンロードすることにする。特にログインセッションが必要でなければ普通にやればいいが、ログインセッションが必要な場合、いちいちヘッダを全部書くのはだるいので、一度 Chrome 上で開発者ツールを開き、リクエストを発生させてすぐキャンセルし、Network ペインで該当リクエストを右クリックして Copy as cURL すると早い。 そのうえでお尻に -o filename -C - をつけてやる、つまり $ noglob curl... -o filename -C - curl... の部分はペースト。noglob は念のためつけておく。-o fil
https://github.com/cho45/CopyHook ペーストボードにコピーが行われたときに、JavaScript で何かするというツールを書いた。 競合するソフトウェアがいくつかあると思うけど (dot-clipboard とか)、すぐできそうだし Swift で書かれたのはなさそうということで書いてみた。 ユースケースとしては Slack のチャット画面を適当にコピーしたのを、自動でフォーマットしてペーストしやすくする リッチテキストとしてコピーされるのがウザいので、プレーンテキストにしてしまう 画像を自動でグリッチする というのがあります。 つかいかた 起動するとアクセシビリティを有効にしろといわれるのでする 有効にしたらもう一度起動する。 コピーのイベントをキーイベントの Cmd+C を見ることで実現している (設定で変更可能) あとフォーカスされているアプリとかウィ
よくあるツールなんだけど、なかなか希望に叶うものというと見つけにくく、どうせなら自分で書いたらいいかと思ったので書いてみた。やってみたら割とすぐ書けた。 MacRuby のインストールが必要。1ファイルにしたかったので、XCode なしで使っている。あんまり XCode なしでの作例がないが普通に NSApplication.sharedApplication を取得したらいいだけだった。 NSEvent.addGlobalMonitorForEventsMatchingMask:handler: は「システム環境設定」→「セキュリティとプライバシー」→「アクセシビリティ」で macruby を許可しないと使えない。これができるということは、すなわちキーロガーが実装できるということなので、必要なときだけ許可するほうがいいと思う。 #!macruby framework "Cocoa" cl
最近まで知らなくていちいちコピペして git merge foobarbranch とかやっていたが、 git checkout foobarbranch .... なんか作業 git checkout master git merge @{-1} みたいに、@{-1} を使うと直前に触っていたブランチを示すことができ、これですぐに merge が実行できることを知った。 単にハイフンでいいらしい…… @cho45 これ、僕の環境だと git merge - でできてる http://t.co/8tq4AOmMys — Daisuke Murase (@typester) June 12, 2014 トップ tech git で直前にいたブランチをマージ
を作った。Togetter とかで「ああ、こういう話題に言及する人とは関わりあいたくないな」っていうことが時々あると思いますが、そういうときに使える便利なツールです。 http://block.lab.lowreal.net/ 余談 僕はホワイトリスト的な、つまり Twitter の場合プライベートアカウントだったりあるいは、そもそもフェイスブックだったり、というやりかたが好きではない。当然ホワイトリスト的なソーシャルネットワークのほうが安全ではあるが、新しい思いのよらなさ、というのがないのは詰らない。 しかし一方で、完全にオープンというのも全くよくない。表現をないがしろにするモヒカン的なゴミクズというのはそこらじゅうにいるし、一瞬でも隙を見せれば攻撃してくる人というのもいる。いろいろ面倒なことになるリスクだったり、思いもよらず傷つくリスクのほうが、思いもよらず良いことがある、というメリッ
テストとかでやりたくなると思うけど、こんなくだらないことに gem とか使いたくないので、簡単に書ける方法をさがしてる。 class Foo def hello puts "Hello" end end みたいなクラスがあったとして、hello メソッドを一時的に上書きしたい (そして戻したい) とき あるオブジェクトのメソッドだけを上書き これは singleton class を使ったらすぐできるのでかんたん foo = Foo.new orig = foo.method(:hello) # 元のメソッドを呼びたいときだけ必要 foo.define_singleton_method(:hello) do puts "before hello" orig.call puts "after hello" end foo.hello #=> # before hello # Hello #
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
このエントリは古いのでアテにしないでください。新しいスクリプトは userscripts.org で公開され、CodeRepos で保守されています。 mallowlabsの備忘録 - ポップアップ型英英辞書 見てて選択したらすぐ検索できるのっていいなぁと思ったので似たようなのを作ってみた。 fastlookupalc.user.js 相違点 英和 (alc) 一個ひいた後に、さらにひける。(こういう機能は英英のほうが便利だけど) 結果のタイトル (赤い部分) をクリックするとその結果だけ消えます。ドキュメント内のどっかをクリックすると全部消えます。 ダブルクリックで単語を選択するのでどんどんひける。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く