上京するときに必要な準備のまとめ
こんにちは。
先週札幌から東京に来たばかりのひよっこが1週間実際に東京に住んでみて
「これは準備しておけばよかったなぁ...」
「これは準備しておいてよかった！」
と思うものが色々と分かったのでこのブログに纏めておきたいと思います。
準備しておいて良かったもの
2.MacBook Air
MBAに限ったことではありませんが、
インターネットに繋がる環境とPCを用意しておくと良いと思います。
東京での生活における質、仕事の成功確率がグッとあがるのは間違いありません。
今後、万が一の時はお金にできる、という利点もあるかもしれません。
3.目標の整理
わたし自身完璧に整理していたわけではありませんでしたが、
自分の夢や人生における目標を整理しておくと、
東京に来て次に自分がとるべき行動が明確になり、様々な面で効率が良くなります。
また、苦しい局面でも精神的な負担が減り、楽しいと感じたりするようになります。
上京するしないに限らず個人的にとてもオススメしたい準備です。
準備しておけば良かった...もの
1.足腰の鍛錬
東京は本当に広いです。
電車の乗り換えや自宅から駅への徒歩、目的地への徒歩、かなり足腰を使います。
極度の運動不足にも関わらず、東京に出てすぐに肉体労働をしたせいもありますが、
来て1週間は毎日足が痛くて、はりっぱなし、水ぶくれもたくさんできました。
なので、まずは足腰を鍛えておくと良いです。
また、日雇いの建設現場などのお仕事も足さえついてくればいくらでもできます。
お金がなくても、家がなくても、きっとなんとかなります。
どうしても、という方は自転車生活のための費用を準備しておくと吉です。
2.お金
初めての土地で家を借りて生活してみると、予想以上に必要なものがでてきます。
1ヶ月分の家賃程度で良いので、少しでも貯蓄を用意しておくと、
効率のよい生活ができるようになると思います。
飛躍する自信のある方は、最悪魔法のカードに手をだすのもありかもしれません。
3.友達
できれば一緒に上京する友達や、東京に住んでいる友達がいると良いです。
自分の目標のために突き進んでいても、やはり寂しさは残るものです。
わたしはさっそく旧友2人と会いましたが、
濃密な時間を過ごす事ができて本当に励まされました。
4.家
札幌を出ると決めて1日で家を契約して
2日後東京に来たのですが、これが大失敗でした。
いまは部屋という概念が失われたシェアハウスの中で、
普通の音を出すこともはばかられる状況になってしまいました。
ちなみにですが、この部屋（ではない空間）のカギはナンバー式の南京錠です。
ネットで検索すると家の間取り、写真を確認できますが、
物理的・金銭的な余裕があるなら必ず実際に行ってみて、
家の下見をしたほうが良いです。
5.服
北海道からきたわたしから見て、
東京はこの時期でもかなり暑く大量に汗をかいてしまいます。
服が少ないということは、その分洗濯に割く時間が増えるということになります。
替えの服は最低でも2日分、余裕をもって4日分は欲しいところです。
以上です。
これから上京を考えている、どこかの誰かの参考になったら幸いです。
スタートアップ
あけましておめでとうございます。
私はどうやらお酒が入るとブログを書きたくなるらしい。ちゃんと調べれば、今までのブログ記事の中で技術的ではない内容のほとんどがお酒が入った時に書いている、という統計結果がでるだろう。
そもそも、朝仕事に行く時も、時には仕事中も、お風呂に入っている間も、寝る前も、わりと色んな事について考えていて、ほんとうはブログにガンガン投稿していきたいのだけれども中々面倒くさがりだったり、恥ずかしい内容なので書くのを控えてしまう。
それでも今年は色々吐き出していきたいなー！
という事で、まずは今年の豊富、スタートアップの話からはじめようと思う。
-
-
-
- -
-
-
何かをしたい、はじめたい、でも中々できない。
私も去年Trelloで管理していた目標のほとんどが達成出来ていない。
なぜ達成できなかったのか、過去に達成できたり、できそうだったりした目標と何が違ったんだろう。と思い返してみた。
わたしはどんな物事でも成す事はとても簡単だとなめきっていて、
ほんとうに単純な意識の違いでしかない、と思っている。
何か目標をたてて、それが達成できなかったとしたら、話はとても単純。
意識が低かったんだ。はいおしまい。
意識が低い状態になると、ひとは怠けようとする。
うまくいかなそうでも興味がなくなる。
失敗したらひとのせいにする。
これは勉強でも、仕事でも、遊びでもおなじで、どんどん目標から遠いほうにむかってしまう。
そのほうが楽だし、頭をつかわずにすむ。
（ただ、成功体験の少ない人や自分に自信のない人は無理に目標をたてないほうがよいかもしれない...。）
では具体的にどう意識が低かったんだろうか。
これも単純な話だった。
目標に具体性がなさすぎた。
○○を成功させる！ → 成功ってなに？
○○をつくる！ → どうやって？
○○をつくるために作戦をたてる！ → どうやって？
○○をつくるために作戦をたてる時間をつくる！ → どうやって？
曖昧な目標ほど意味のないものはない。
とくに成功や失敗というような具体性のない目標は、たとえそれがうまくいっても全くもって意味がないだろう。
よく、目標は人に話したほうが良いというが、この辺の具体性を補強するためなのかなとも思う。
○○をつくって1000人に使ってもらう！
○○をつくって1億円儲ける！
というように具体的な目標にしなければ、それがうまくいったか反省すらできない。
これがちゃんとした目標だ。ちゃんとした目標を持とう！！
そして目標の維持のしかたについてだけれども、
必ず、大きめの紙を用意して、自分の手で、できるだけ太いペンではっきりと目標を書く事。それを見える場所に貼ること。
これが大事。去年わたしはTrelloという素晴らしいツールに目標を書いて、Chromeのホームページにして毎回開くように設定していた。
私の中で薄々気づいてはいたが、これでは全然だめだ。
毎日現実世界の目標として、リアルな目標を見て感じて考える。
そのためにはやはり、紙に書いて貼ることが最も重要だと思う。
- 目標は現実的に、実現方法も含めて具体的にたてること
- 目標が決まったら必ず紙に書いて見える場所に貼ること
今年の抱負ではしっかりと実践していこうと思う。
Ruby on RailsのMySQLバックアップタスクを書いてみた
以前Fuelで書いたバックアップタスクがあるのですが、あれの安心感が結構あったのと、いま作っているものが Ruby on Rails だったので、さっくりrake版を書いてみました。
大したものではありませんが、なんとなーくConfigの触り方が分かりました。
rubyでyaml読むの楽ですね！
database.ymlに追加でbackupdirを設定できるようにしてみました。
コマンドラインと自動実行、apacheから呼ばれた際のユーザーの違いによる権限エラーにご注意ください。
mysql.rake
https://gist.github.com/letsspeak/7988055
Ruby on Rails mysql backup rake task
javascriptのcanvasで画像を自由にトリミングしてアップロードする機能を作ってみた
今回はjavascriptで画像をアップロードする際にトリミングするコードをcanvasを使って書いてみました。
趣味でゲームのスクリーンショットをアップロードしてみんなで見せ合うようなWebアプリケーションを作っていたのですが、元の画像サイズやファイル形式って人によってまちまちだったりします。
ゲームということもあり、デジカメのような大きすぎる画像サイズになることはないのですが、どうしてもプライベートなチャット内容が入ってしまうのは嫌です。できれば自分の見せたい範囲だけをアップロードしたいものです。
また無圧縮のpngやbmpなんかでアップロードされた場合、数MBの画像をやりとりする分けにはいきません。そこですこし劣化したjpeg等の圧縮された画像形式に変換することになりますが、これをサーバー側で行うと、プレビュー画像をユーザーに見せるタイミングがサーバーで処理を行った後になってしまい、ユーザーの時間とサーバーリソースが無駄に消費されてしまいます。
そんな訳ですべてjsのcanvasでやってしまおう！という感じで実験しつつ作ってみました！
trimming_upload.js
https://github.com/letsspeak/trimming_upload.js
行っていることは、
1.ファイルが選択されたら画像を読み込む
2.この際、画面表示用のlayer1には設定された最大サイズで比率を維持して読み込む
3.また裏のbaseに元画像のサイズのまま読み込んでおく
4.画面表示部分がクリックされた際にlayer2にトリミング用の矩形を描画する
5.画面には常にlayer1とlayer2を合成して表示する
6.トリミング確定後、アップロードボタンが押されたら元サイズのbaseボタンからトリミングサイズに基づいた比率で切り抜いてデータを送信する。
という感じです。
こんな感じで設定した最大さいずでプレビューしつつ、トリミングは元画像の比率で行うようになっています。
今回のハマりポイント
context.drawImage() の際の第一引数になるcanvasサイズが width, height ともに 0 の場合に例外が発生するようです。これに気づかず20分程はまってしまいました...。
書いていて気がつきましたが、元のトリミングサイズのままアップロードしたい場合の処理がありませんねwこの辺を次の課題としつつ今回はこの辺で終わりとさせていただきます。
ではよいお年を。
電脳化の話メモってなかったので
忘れる前に書いておく。
インプットにせよアウトプットにせよ、その信号が何を表すかというのには個体差があるのではないだろうか。
全ての存在する概念について人間個体の脳結合要素を洗い出してるうちに人生が終わりそう。
と思って結構悲観的に考えてたけれども、今思ってみると概念まで直接伝達する必要は微塵もないな。
むしろそれは200年後の話で、とりあえずのところは5感にインプットすればいいじゃん。はい解決。
ec2にhaskell-platformをインストールする
噂のyesodさんを試してみたいと思いつつ、手元のmacで失敗した経緯をもとにインスタンスをすぐ消したりできるec2を使って試してみました。
インスタンスの立ち上げ方については詳しいページがあると思うので割愛！
最初はさくらVPSで使っているCentOSと同じRed Hat Enterprise Linux Server release 6.4 (Santiago) を選択しましたが、haskell-platformのmakeで失敗しました。
はっきりいって初心者の自分には何が理由で失敗したのかさっぱり分らなかったので、気を取り直してAMIでインスタンスを建て直し、試しにRed Hat と同じコマンドを打ってみたところhaskell-platformのmakeが順調に進み....謎の失敗。
ググってみると下記のブログがヒット！
AWSのアカウントを作ってみた
http://amkkun.hatenablog.com/entry/2013/02/06/183901
どうやらマイクロインスタンスではメモリが足りないという事で、一時的にスモールインスタンスに変更してmakeを実行します。いつもいつも先駆者の方々に感謝です。
macであれほどうまくいかなかったcabal-installについても、一度は失敗したものの先述のmake時と同様にスモールインスタンスで実行したところ無事成功しました。
一通りの手順は下記に纏めておきました。
set up yesod on ec2 Amazon Linux AMI 2013.03.1 64bit
https://gist.github.com/letsspeak/5650158
haskellぐぬぬって感じは未だに拭えないです。
無事yesod環境構築できた暁には、AMIのスナップショットを保存しておきたいなー
ファイルの所有権について
ファイルシステムって概念自体を理解する事が難しい。
デジタルネイティブなら普通に理解していたりして、現状のままでも良いのかもしれないけど、もうちょっと理解しやすいファイルシステム無いのかなーとか、なんで理解しづらいのかなーとか、ファイル名以外からファイルを特定する手順についてほんの少しだけ考えてみた。
そこで思ったのが所有権。
ファイルから名前という属性を取った時に一番最初に思うのは、○○さんから貰った○○。
今のPCってファイルを端末間でコピーしたら所有権は基本的に委譲されるけど、これってかなり重大な設計ミスなんじゃなかろうかー
真逆の発想をとると、ファイルの所有権なんて無視してすべてのファイル誰でもいつでも見れるようにしてしまう。
私の煩雑なデスクトップをコンピュータさんが自動的に整理するためには、どちらかが必要なんじゃないかなと、なんとなく思ったのであった。
追記：
ファイル共有で動画でもアニメでも音楽でもなんでも無料で配信してしまってから、支援者がお金を払うシステムっていいんじゃねってちょっと前に思っていたけれども、人間無料で手に入れられるものは無料で手に入れてしまう。（それによって相対的に自分の価値を下げてしまうにもかかわらず。）
で、これの問題点を解消するべく、お金を払って得た人と、はらわずに得た人を晒しものにしてしまえば良いのではなかろうか。などと思ったところで、ニコ生ってすげえなと思いつつ寝るのであった。
