プログラマ行進曲第二章

主にソフトウェア関連の技術をネタにした記事を執筆するためのブログ

Go言語(golang)の文字列とかスライスの扱いを少し勉強した

プログラミング golang

Qiitaに投稿したので今日はもうそれでブログ更新終わりにしたい。

ということで記事のリンクとコードをぺろっと貼って終わりにする。

リンク

Go言語でスライスとか文字列関係の勉強をしてみた

書いたコード

Go言語でスライスとか文字列関係の勉強をしてみた ref: http://qiita.com/tak ...

ブログカスタマイズとデザイン、HTML/CSSとJavaScriptなど

雑文 デザイン ブログ

今日も雑文です。書き散らし。

JavaScriptとかCSSとか分からないから滅法ハンデ背負ってる

photo by Tricia Wang 王圣捷

週末で時間もあるし、今日こそは技術的記事にしようかなとか思っていたのですが、夜に空手稽古とかあって時間気になって調整できなかったので、また雑文です。

が、ちょうどいい機会だと思ったので、ブログカスタマイズに少し手を出してみました。

パッと見変わったところが分からないと思いますが、実はサイドバーに「人気記事を追加」と「カテゴリーをタグクラウドっぽく字の大きさを変える」ということをしてみました。

で、ここで思い知ったのが「HTML/CSSやJavaScript(というかjQuery?)を知らないとこういったちょっとしたカスタマイズですらハンデ背負うんだな」ということでした。

というのも、ブログカスタマイズとかあんまりしたこと無いのでどうやるのかなー？なんて思いながらググって調べてみたら、私がやりたいようなことはだいたいCSSとJavaScriptを使わないと無理だって事がよく分かったんですよね。

本当に初歩的なことなら分かるのですが、ほんのちょっと細かいところに手を加えたくなったら途端にこれらのしっかりとした知識が必要になってきて「うーん、このままではマズいなあ…」と思わざるを得ない事態です。

今年はブログカスタマイズを皮切りにしてCSSとかJavaScriptとか今まで手を付けていなかったところを埋めていくのを目標にするのも良いかもしれないかな、と思いました。

手抜き記事でお茶を濁す

雑文

昨日golangのWebアプリケーションフレームワークのMartiniの軽い説明をしたので今日もそれをやろうかなと思っていたのですが、何故か一日が過ぎて更新する時間が無いので明日に回そうかなって思います。

というのも、一昨日辺りからデプロイに失敗したのか、Google App Engine上に乗せていたMartiniアプリケーションが動かなくなっていたやつの面倒を見ていて時間を取られていたので。まあ、以前の記事にも書いたと思うんですが、単なるプロフィールサイト(しかも未完成)なんですが。

とはいえ、MartiniをGoogle App Engine上で動かすやり方も分かってきたので、そういったものの紹介するだけでも価値があるかなと思うので、しばらくブログ更新ネタ自体は尽きなくて済みそうですね。

Go言語(golang)のWebアプリケーションフレームワーク、Martiniを動かしてみる

プログラミング golang

最近Go言語のWebアプリケーションフレームワークのMartiniをいじってます。今日はそのMartiniの動かし方でも適当にアウトプットしようかなと思います。と言っても公式に書いているもののほぼ写しですが。

前準備

Go言語自体のインストールとかは割愛。1.1以降が必要みたいなので、最新版をインストールしましょう。

そうしたら次にフレームワークそのものをインストールしましょう。

go get github.com/codegangsta/martini

go getする際にグローバル環境を汚したくないという人は、お好みでgoenvとかgomとか、そういった類のツールを活用すると良いと思います。

動かす

ぶっちゃけREADMEに書いてあるものそのまんまですが、以下のようなコードを書いて保存しましょう。

gist8454383

これをserver.goみたいな名前で保存した後、go run server.goで実行すると動きます。デフォルトで使用するportは3000なので、http://localhost:3000/ にアクセスしましょう。画面にHello world!と出てきているはずです。

ちょっとした応用

上記コードを見れば何となく分かるように、martiniのインスタンスmを使ってm.Getの第一引数にURLパターンを指定し、第二引数にハンドラを指定します。上記の場合だとハンドラは単にstringを返す関数を指定しています。ちなみにm.Get()は見て分かるようにGETメソッドに対応しており、POSTを受け取りたいときはm.Post()、DELETEを受け取りたいときはm.Delete()などが用意されています。渡す引数の種類も同じ(はず)です。

で、少し書くだけで分かると思いますが、URLパターンの数が多くなって指定する数が増えるとmain関数内にm.Get()などをその分だけ書くのですが、その際、ハンドラをそのまま直に書いていると後でメンテしづらくなると思うので、関数を宣言しておいてそれを呼び出すようにするとスッキリすると思います。以下、上記のコードを分離した例です。

gist8454399

Martiniを使ってみての感想

今現在、実際にMartiniとGoogle App Engine使ってWebアプリを動かしている*1のですが、PythonにおけるFlaskのような感覚でWebアプリが作れるので、個人的にはシンプルで気に入っています。

あと何といっても、2014年1月16日現在ではMartiniのコード量もそう大して多くないので、挙動が気になったらソースコードを読みに行けば解決することができるのもいいですね。今までWebアプリとか作ったことなかったのですが、シンプルで薄いフレームワークなので勉強になります。

今Google App EngineにデプロイしているMartiniを使ったWebアプリ(ただし単なるゲストブック)のエラーが戻せたら、MartiniとGoogle App Engineの組み合わせをどうやるかもブログにしてまとめたいですね。といっても公式READMEにやり方書いてあるんですけどね！

*1:といっても単なるゲストブックアプリで、しかも2014年1月16日22:15現在、デプロイの失敗のせいか、golang標準のhtml/templateのエラーが返ってきて動いていないのですが…

今日学んだこと-シリーズ2

本 プログラミング 雑文

新年明けてから(ほぼ)毎日ブログを更新することでだんだんリズムが取れてきて、更新すること自体へのハードルは下がってきました。後は限られた時間の中で記事の質を上げていくことを考えていかないとな−、って思ってます。

What I learned today

前にも同じような記事を書きましたが、「ネタに困った」or「短時間に書き上げたい、書く時間を確保できない」という時の緊急手段的なエントリとして活用しようかなと思います、このテーマ。

今日は以下の本を軽く読んだってことで感想をちょろっと書いてみます。

Learning Python Design Patterns

Learning Python Design Patterns

本当はさっさと読み上げたいんですが、コード書く時間も少なくなってきてそっちに時間を割いていると中々本を読む時間を確保できないというのはエンジニアあるあるなんでしょうねえ。

で、肝心のこの本ですが、ようやくChapter 3のFactoryパターンの最後の方まで読むことが出来ました。

全部でChapter 7なのでまだ半分にもたどりついていませんが、その中で感じたことなど。

この本はFactoryやFacadeなどのパターンをPythonで実装する場合のコードも掲載しながら各パターンを解説しているのですが、実用的なコードというよりも解説用のコードになっている感じがするので、「今までデザインパターンのことを全く勉強してなかった人」でPython読める人が対象読者なのかな、と感じました。

逆に言うと、今までどこかでデザインパターンのことを勉強していたり、あるいは勉強していなくてもデザインパターンに則った形で実装することが出来る人は読む必要がないものなのかな？と思っています、今のところは。

まあ、私は今までデザインパターンの勉強をあまり出来ていなくて、結城浩さんのJavaでのデザインパターン本も途中までしか読めてない(※Javaをあまり読めないから)状態だったので、ちょうどいい教材になっております。

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

原著も含めたデザインパターン関連本でも貼っておきます。特にアフィリエイトを設定しているわけではないので適当に踏んで買ってみると良いかもしれませんね。

技術系記事投稿先としてのブログと他のサービスの使い分けとか少し考えてみた(※あくまで私の場合の話し)

考察 プログラミング

こうやって毎日ブログを更新していくと段々とネタがなくなっていくかと思いきや、しょぼいものならぽんぽん出てくるので、「とりあえず書く」という行動を起こしていくのが大切なんだろうなと感じている最中です。

で、今日書く内容ですが、特に考えていなかったところ、こんな事を思ったので書いてみます。

技術系記事の投稿先の方針とか再考し直してみた

要するにコードを公開してアウトプットする場所をこのブログだけじゃなく、他の所も活用しようかなと思ったってことです。

もっと具体的にいうとQiitaの私のページに「細々としたコードの断片とかちょっとした試行錯誤の結果」を投げつけるように投稿しようかなとか思っています。*1

思えば去年、プログラミング系の記事で書こうと思っていてネタも十分あったのに上手くアウトプットできていなかったのは「その記事単体を読んだだけで一通り分かるような体裁で技術記事は投稿するべきだ」という強迫観念をいつの間にか持っていたことが原因だったのではないか、と今年に入ってから思うようになりました。

そういった強迫観念で技術系記事を投稿しないという状態を続けていると

  1. 「技術系記事を投稿しない」
  2. 「技術系記事の書き方がいつまで経っても上手くならない」
  3. 「書き方が上手くならないから更に投稿しなくなる」

というループを続けてしまうのではないか、というかそういう状態だったよな、と感じるようになったので、「それなら下らないとか詰まらないことでも投稿してもいいという心持ちに向かうような仕組みを自分の中にこしらえればいいんじゃないか？」というのが思考の出発点です。

別にQiitaに限定する必要は無いんですが、Kobitoとかあってすぐ投稿できる体制が整っているところ、他にないので。

直近の課題としては「試行錯誤したコードとかその時のやりとりをなるべく手をかけずに記事の形にするにはどうしたらいいか？」というところですね。

試行錯誤した後に改めて記事を起こそうとすると負担が大きいのはやる前から予想できますし、実際今こうして書いている文章も即興で書いているんですが結構辛いので、そこら辺もプログラマらしく仕組み化してアウトプットできるようにしたいなあとか夢想してます。

で、早速適当な記事を投稿してみました。

既に同じテーマでずっと良い内容をQiita上で書いている人がいますが、そんなの気にせず適当に書いて投稿しました。

今こうやって書いて思いましたが、ちょうど今使っているemacs evilの設定を作り混んでいく過程を残しても良いかもしれませんね。

ブログの見栄えを再考する必要あり

あと、技術系記事投稿先の話しとは少しずれるのかもしれませんが、はてなブログにしてからレイアウトとか記事の一覧性とか全く気にかけていなかったけれど、このブログを自分のアウトプット場所＆アピール場所として考えるならお勧め記事の導線くらいは作っておかないといけないだろうなあ、と思いました。なので、近日中に手を付けたいですね。

手を付けられるならね！

*1:ちなみにステマじゃないです。お金もらってないですし関係者いないですし。

miyagawaさんがオススメしていたTech Podcastを英語リスニングも兼ねて最近聞き始めている

英語 プログラミング

タイトルで全て言いたいことを言ってしまっているんですが、一応軽く経緯とかも書いてみます。

未だ無職のくせにこの1月の頭からとある所に朝の通勤ラッシュ時間帯に電車に乗っていかなくてはいけなくなったので、その時間を有効活用したいなあと思っていたところ、普段聞いているrebuild.fm関連でmiyagawaさんが以下のエントリを書いていたことを思い出しました。

文字通りTech系Podcastのオススメが書かれていて、候補も5つとちょうど少なそうだと思い、電車に乗って揺られている時間とかぼうっとして頭が働かないときに音楽代わりに聞き始めています。

「Podcast聞いて技術的なことを吸収する」というよりかは単に「英語リスニングの機会を増やして時たま訪れる英語コミュニケーションの場に活かそう」、くらいの適当なノリです。なので肩肘張って一生懸命聞くわけではなく、分からなくても適当に聞き流しています。というか聞き流している方が時間が長いくらいです。

で、どうせ聞き始めるなら雑多な種類をたくさん聞くよりかは少ない種類に絞ってやった方が持続しそうなので、miyagawaさんのエントリから派生して検索して、以下の記事とかも含めて参考にして選びました。

というわけで私はAccidental Tech Podcastを主に聞いています。サブでThe Web Aheadを聞いています。というかまだこれくらいしか取り組めていません。

なぜこの2つにしたかというと、上記で挙げたエントリ群を読んで以下の点が気に入ったからです。

  • 1つ当たりのエピソードの時間が長い
  • 定期的に配信されている(いそう)
  • 人との会話のやりとりが中心(な感じがする)

意味が分からなくても1つ当たりの時間が長い方が(私の場合)飽きずに聞いていられそう&英語リスニングの訓練になりそうですし、習慣化しようと思っている場合には定期的に配信されているかどうかは重要だと感じていること、一方的な講義的なものよりかは会話のキャッチボールが激しいものの方が実際に英語コミュニケーションを行う時のシミュレーションになっていいだろうと思ったことなどが上記3点を重視した理由です。

実際に習慣化するかどうかは分かりませんし、英語リスニングのためになっていくのかどうかもよく分かりませんが、新年になったので新しいこと始める第一歩にしてみようかと思います。