TwitterのRSSを生成する Twitter Great RSS をつくった

つくりました。
Twitter Great RSS

  • 1人のユーザーのツイート一覧
  • list
  • 検索結果 (←NEW!)

RSS化できます。
検索にも新たに対応しました。エゴサーチが捗りますね!


以前つくっていたもの(Twitter Good RSS)が、一部壊れているようで新規登録ができないとの連絡を受けていたんんですが、以前のやつは今見るとDB周りが色々絶望的で直したくなかったので新しいものを作りなおしました。

機能的にも上位互換なので今後はこちらをお使いください


Twitter Great RSS


GitHub

neovimで新しくなったところまとめ

neovimは「vimを近代化させよう」というvimのforkです。

https://github.com/neovim/neovim
http://news.mynavi.jp/news/2014/02/26/097/

なかなかかっこいいので、現状どのような改修が行われたのかcommitを追いかけてみました

TL;DR

  • 開発始まったばっかりなので総Commit数まだ少ない
  • CMake使うようにした
  • ゴミ掃除とサポートしたくない環境の切り捨てをした
  • 実用段階になるには少なくとも半年以上はかかりそう

詳しく


Import vim from changeset v5628:c9cad40b4181

  • ファーストコミット
  • いらなそうなファイルとかマクロとか消したらしい
  • Cmakeにビルドを移植したらしい
  • fork元との差分はなし。あんまり丁寧じゃないね


Fix build on OSX/Archlinux and add README

  • SELinux対応面倒なのでとりあえずコメントアウト
  • OSX/Archlinuxでビルドが壊れているのを修正
  • OSXでlibintl(gettextなどから使用される)を探すように&なんか色々ハックしてる
  • Archlinuxでリンク時に-ltermcapをつけても名前が見つからずリンクできないのでtermcapを包有しているcursesをリンクすることで(-llibcurses)回避

わりと雑なハックが行われている模様


Remove more #ifdef dead code

  • 古いマクロとかさまざまな環境に対応するためのコードとかをごっそり削除
  • Mac OS 9とかBorland C++ CompilerとかMSDOSとか
  • libuvの乗り換えるためかsys/poll.hとか使うのやめている
  • GUIは別プロセスにしてTCP接続する疎結合に切り替える予定のためかGUIまわりのコード(X11, GTK, ...)もごっそり削除


Automate libuv download and build

  • libuvを自動ダウンロード&ビルドするように……ってそれmakeでやることなの? aptなりyumなりbrewなりに任せるべきでは


Add libtool to OSX installs
Add Arch dependency instructions to README.md

  • それぞれOSXとArch Linuxでのインストール手順説明の修正
  • Arch Linux向けのcommit複数あってそれぞれ別の人がやっていて流行っている感じある


include a copy of the Vim License

  • うっかり忘れていたっぽい。雑っぽい


Cleanup refactoring in main
Clean up main.c:parse_command_name


Add travis-ci configuration

  • TravisCI導入


First pass on getting build working on FreeBSD.

  • FreeBSDでビルドできるように
  • みんな自分のOSに対応させるし使ってないOSはどうでもいいということがわかっておもしろい
  • バザール開発だ


README.md: fix ubuntu/debian deps

  • 「For Ubuntu 12.04」ってなんだよ、俺はdebian使ってるんだという心の声が聞こえる
  • build-essentialはubuntuにしかないんだよ。要するに必要なのはlibtool, autoconf, g++だという心の声が聞こえる

追記: debianにもbuild-essentialはあるらしい(thx KoshianX!)。今手元のsqueezeで確認したら確かにありました。build-essentailではlibtool, autoconfは入らないようなのでそこを直したと思われる


Added 'neovim' to the feature list, following discussion on #44

  • VimLからhas("neovim")でneovimがどうか判定できるように


scripts/common.sh: remove a couple bashisms


追記:bashでしか動かないバグをbashismsというらしい(thx KoshianX!)。

シェルスクリプト詳しくないので精進します


Adding neovim formula for Homebrew
Updating README file to use Homebrew for local builds

  • Homebrewのfomula書いたぜ
> brew install neovim/neovim/neovim

でneovimが入る便利ライフに

コーディング規約とかガイドとかって難しいよねという話

注:細かくてどうでもいい話です

Cookpadの規約スタイルガイドについての話
https://github.com/cookpad/styleguide

[SHOULD] ハッシュのキーを Symbol にして良い場合は、文字列よりも高速に lookup できるので積極的に Symbol を使うこと。

ここの箇所、言いたいことは分かるんですがちょっと誤解を招くなと思った
具体的には

  • 「可読性と一貫性」*1を目的にしているならパフォーマンスの話をするのはおかしい
  • ハッシュのlookup速度が問題になるケースはかなり少ないので、一般的な状況ではキーをSymbolにすることにパフォーマンス上の優位点はない
  • SymbolはGCされないので新しいSymbolがガンガン作られる状況(ex. ユーザからの入力を.to_symする, 巨大な文字列の集合を.to_symしたものでハッシュをつくるなど)ではメモリリーク*2が発生する。

という問題があると感じた。

で、r7kamuraさんに聞いてみたところ
いくつか勘違いしていたことに気づいた

  • ガイドなので規約ではなく必ず守らなければならないものではないらしい*3
  • ずっとリテラルの話をしていてのこの節なのでインスタンスではなくリテラルの話だとわかるはず(つまり空気読めていなかった)

こうしたらいいんじゃないかなという解決策

↑のようなことを丁寧に書くとクソ長くなってしまうのでもっと率直な理由にすればいいのでは

[SHOULD] ハッシュのキーを Symbol にして良い場合は、タイプしやすいしかっこいいので積極的に Symbol を使うこと。

*1:https://github.com/cookpad/styleguide/blob/master/ruby.ja.md#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB

*2:これを厳密な意味でのメモリリークというかは知りません

*3:じゃあmustとか書かないほうがいいのでは

Conference With Developers 2 を開催します

2月1日にConference With Developers 2というイベントを開催します。


昨年に引き続き今回は、

という、iOS界で今をときめく/不動の大御所な皆様にお話しいただきます。


LTも募集中ですのでぜひご参加ください


http://confwd2.peatix.com

そして老害になる

闇 Advent Calendar 2013の7日目として老害化の話をします。



ベンチャーじゃなく大企業につとめてよかったことは、さまざまな技術バックグラウンドを持つ人と仕事ができていることだ。


色々な流儀や文化の人たちと接し、ぶつかることで自分の視野がどんどん広がっていくのを感じている。


昔話をすると、学生時代、自分は主にRubyを書いていてJavaPHPをダサいものだと考え、時にはそれを口にすることもあった。
しかしdisるための根拠などをしっかりと持っていたわけではなく、なんとなくで
最新技術=かっこいい、べんり
古い技術=ださい、めんどくさい
と考えていた


社会人になってからダサいと思っていたまともなPHPの書き方を知りそれはそれで悪くない、むしろRubyよりすぐれだところもたくさんある素晴らしい道具と知った。


逆にcoolだと思っていたnode.jsやCoffeeScriptに手を焼き、PhoneGapのような技術で作られたプロダクトに苦しめられもした。
それらをiOSネイティブに書き換えていく作業をするなかで見た目だけで敬遠していたObjective-Cの思想が大好きになったりもした。


DB設計の正しいやり方を身につけ、それまでに自分がActiveRecordのmigrationで適当につくったものがいかにひどいものだったかも知った。


経験を積めば積むほど、今まで自分がバカにしていたものがいかに優れているかがわかるようになったし、逆に今まで無条件で最高だと考えていた技術の欠点も見えてきて、新しい技術が単に新しくてcoolそうだというだけで飛びついたりすることは減ってきた。


エンジニアは気付けば新しくて楽そうなものに流れる傾向がある。
しかし、最高のまともなエンジニアになるためには新しいもの、古いもの、有名なもの、無名なものをイーブンに評価できるようになるべきでなのではないだろうか。


そう考えもあり、最近はC++をずっと勉強していて楽しい。Javaも深く知りたい。他にも知りたいことがたくさんある。


しかし、そういうことをやっているとどんどん周囲と考えが離れていくのを感じる。技術の話をしても噛み合わないことが増えてきているような気がする。


Rubyやnode.jsかじったやつが使ったこともないのにPHPJavaを叩いてるのを見るとぶん殴りたくなる。
RDBの大した知識もないのに「MySQLはめんどうそうなので、MongoDBを使おう」などと提案されると軽蔑してしまうしそいつとは仕事したくない。


このままいくと将来こんなことを言ってしまうかもしれない
「プロダクションでnode.js使うの?いいけど何か問題が起きたとき対応できるの?nodeのソースコードすら追えないじゃ困るじゃん。C++も読めないのに偉そうなこと言うなよ」


そして老害になる

iOSの隠しフォント,ヒラギノ角ゴW1を使ったアプリが審査通った件

Animetick for iOS 1.2が審査に通り、リリースされました
このアプリでは隠しフォントっぽいヒラギノ角ゴW1を使用しています。


.HiraKakuInterface-W1, .HiraKakuInterface-W2というフォントは
iOSの標準API(UIFont#fontNamesForFamilyName:)では取得できないため
Private APIにあたり、Appleの審査で落とされる可能性が指摘されていました

注意

私がセーフだったからと言ってあなたのアプリもセーフとなる保証は全くない