FC2ブログ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
スポンサーサイト

ブログのテンプレートを変えてみた

いままで使っていたテンプレートですが、ブログ書き始めたころ(2012年)当時は良かったものの、今では表示が崩れたりして、見栄えが悪くなってました。

実際だいぶ前からでどうにかしようと思ったはいたものの、テンプレート変えたら表示崩れるかな~と思って放置してました。
ただ、今月に入って引っ越しがあったりして気分的に思い切って変えてみました。

5年以上も経ってるとずいぶん公式のテンプレートも変わってて、結構いい感じのがわんさか。
じつは幾つか他にも初期の頃に追加していたテンプレートがあったんですが全て時代を感じるデザイン。あの時は気に入ってたのに。。
ショックですよねw別に体感的にはそこまで前じゃないのに、こうしてみると結構流行りってあるんだなぁみたいな。
みんな街歩いててもここ15年くらいはずっとおんなじような格好してるし、変化がないな~なんて思うんですけどね。2000年くらいだと流石に90年代引きずってる感がありますが。

でも、実はこのブログ自体引っ越そうかなとか思ってたりして、今別のブログをお試しで使ってる感じなんですよね。

WordPressは結構メンテが面倒臭いんでもういい加減辞めたいとか思ってます。でもWordPressに関しては無料ブログサービスとデータの移行をするにも面倒だったりするんですよね。だからそっちはやめようにもやめられないとまらない。WordPressはそのまま出来る限りプラグインで自動化するのが一番いいかなとか思ってます。
なんかいい方法知ってる人いたら教えて。

GoのHTMLテンプレートエンジン yosssi/ace の使い方

github.com/yosssi/ace の使い方について、あまり記事が無いので(特に日本語は)、まとめて置きたいと思います。

まずは、READMEを見ましょう。
基本的な使い方は以下に書いてありますが、順を追って補足していきたいと思います。
https://github.com/yosssi/ace/blob/master/documentation

Go上でのコード(APIの使い方)
以下のページのような使い方をします。
https://github.com/yosssi/ace/blob/master/documentation/getting-started.md
が単純な例しか載ってないので、ここでは私が今回Webアプリの開発に使ったフレームワーク Echo でのサンプルコードを紹介します。

WebフレームワークEchoでテンプレートエンジンAceを使う

上記のページで説明があるように、Ace-proxy というものもあります。なお、Load時のオプションとは、テンプレートのBaseのディレクトリや DynamicReload とかのことです。
https://github.com/yosssi/ace-proxy

APIの詳しい説明はGoDocに書かれています。
https://godoc.org/github.com/yosssi/ace


テンプレートの書き方
Example は Ace の使い方のほんの一部に過ぎません。

テンプレートの書き方については GitHub 上の Documentation に書かれています。 Ruby の Slim と Node の Jade に似た記法で書けます(完全に一緒じゃないです)。
https://github.com/yosssi/ace/blob/master/documentation/syntax.md
なお、上のページでは出てきませんが、

p <a href="https://github.com/">GitHub</a>

のように、タグで改行せずすぐ後ろに記述する場合は、HTML をそのまま書くことが出来ます。

ところで、上記のページを隈なく探しても、繰り返し出力の定義が出てきません。
出てきませんが、AceではGoの標準テンプレートエンジンである text/template (htmlの方ではない)の記法も含めることが出来ます(一番下のActionsのところで説明されています)。

よって、標準テンプレートには for 文が存在するので、繰り返し出力が可能です(実はこれを知らなくてずっとJavaScriptで書いてました…)。

ここからは、Goの標準テンプレートエンジンの説明になりますが、以下のように使います。
qiita.com/lanevok/items/dbf591a3916070fcba0d

また、for文は以下のように for range で記述してインデックス数を使うことも出来ます。
http://increment.hatenablog.com/entry/2016/04/27/203810


ただし、Goの標準テンプレートエンジンでもそのままでは四則演算出来ません。残念(なので、私は全てGoのコード内で計算させるようにしました)。一応関数を定義すればできるそうです。
http://asakandata.hatenablog.com/entry/2015/05/06/174952



注意点
ここまで、自分用のノートにリンクをまとめたものを書き起こしたものですが、結構自分で使ってて突っかかった部分があったので以下に書きたいと思います。
  • エラー
正直テンプレートのエラー自体がわかりにくいです。Goのコードに問題があるかと思いきやテンプレートのインデントの問題だったりして、意外と落とし穴です。ただし、panic()を使うと取り敢えずテンプレートの問題であること自体は把握できます。
  • =include
インクルードに指定したテンプレート内の{{}}は認識されずそのまま出力されてしまう。標準テンプレエンジンの記法で読み込めば解決するかもしれませんが未検証です。
  • インデント
インデントはスペースにします。タブにするとうまく動きませんでした。
  • コメント
コメントもインデントを意識して、必ずコメントアウトしたい行のコードの先頭に、スラッシュと一つ以上スペースを入れて書かないとエラーになります。


因みにこのAce、Hugoにも使われているそうです。Hugo使ってみたい。
https://github.com/yosssi/ace/blob/master/documentation/projects-using-ace.md

よく考えることは重要

プログラミング作法という本をここ何ヶ月か掛けて少しずつ読んでるのですが、第5章のデバッグが結構面白いです。コードを読むのはちょっと時間が掛かるのですが、時間を決めててもこの章はどんどん先まで読んでしまっています。

そんな5章に「打つ前に読め」ということが書かれていて、「コードを舐めるように読んで、変更を施さずにしばらくよく考えてみること」がデバッグテクニックの一つとして紹介されていました。

私の場合、無駄に考えることが多いです。結局行き当たりばったりで編集して動いたところで、本当にバグの根源になってるところを取り除けたのか不安だし、実際結局バグが直ってなくて、デバッグを再開するハメになったことが何回かあるからなんですけど。
ただ、ひたすら考えるのは一番根本的な解決が出来る唯一の方法だと自分でも思うんですが、結構時間が掛るんですよね。

昨日も研究の主題について、今まで文章に書き起こしてきた研究背景や方向性を洗いざらいチェックして、整理した上でこの研究で最も示すべきことはなんなのか(何を検証して示せばこの研究の背景に貢献できるのか)を丸一日掛けてひたすら考えていました。

今まで立ち止まって悩むのは時間の無駄に思えたり、取り敢えず動くようになればそのほうが早く次に進めるし良いと思ってしまって、結構後ろめたい気持ち(さっさと進めてしまえばいいのにとか、他の人なら同じ時間でももっと先に進めてるだろうにとか)が出てきて、毎回「考えるより手を動かせって」自分に言い聞かせてたんですよね。この本にも「効果的なわりに過小評価されているデバッグテクニック」なんて書かれてますけど。

でも結局自分のためにならないのが嫌だから、投げ出さずに悩んでるわけですし、適当やったってどうせ良いプロダクトなんて生まれないよなーと読んでて思えてきました。

よくTwitterとかで納期が迫ってるからって適当に行き当たりばったりのコードを書いて、取り敢えず問題になってた箇所は修正されたからってリリースしといて、後で痛い目に遭う、みたいな話とかよく見かけますけど、そういうのの原因の終着点って結局ここなんだろうなって思います。しかも、間違いに気づかないままどんどん次の仕事が舞い降りてくるから社員も成長しないという…。
世の中世知辛いですね。

あと、アジャイルが流行ってて、取り敢えずの修正でも完成ってことにしてしまえ、ってことだと思ってる人って結構居そうでそういうのが拍車を掛けてる現場とかあるのかなぁなんてちょっと心配です。

アジャイルは確かに段階を区切って製品をプロダクトしていくんだけど、ある機能を実装してみるってところまでやるってことだったら、そこまでの機能を完全に実装するってことなので、バグが残ったままを許容するなんて真似が決して現場で正当化されないことを切に願ってます(一体どこの誰に対する願いなんだか)。
良いプログラムを作れる現場は少なくともこういうバグをちゃんと直すことに(許容するって言い方は変なので)時間を惜しまない企業だと思います。
これだから日本はーとか、日本が日本がーっていうのはどうせ他の国だって駄目なところがあるだろうから嫌いなんですけど、他の国と比べないにしても、仕事をかき集めて短い時間で大量に製品を作ることが最も効率的で利益が上がると思ってる管理職だったり経営者だったりが日本には少なく無い数いると思います。
でも、プログラムの場合はバグの少ないプログラムこそが信頼できるし、安定した利益に繋がる筈なんです。逆にバグだらけのクソプログラムばかり生産する企業なんて信頼できないし、そういう会社は実際に叩かれまくってます。皮肉にも技術者が居ないから潰れるほど需要はなくならないのかもしれませんが。プログラムなんて幾らでも複製出来るんだから、圧倒的に量より質を重視すべきだと思うんですが。
そもそも問題箇所の修正だけしか確認出来てないのにそのままの製品プログラムなんて外面だけ綺麗にした欠陥商品と同じで、ハッキリ言って詐欺ですよ。完璧には無理でも余計なバグが出ないかぐらいはテストしてからリリースしないと許されないように世間の目も変わってくれると良いんですけど。

なんか書いてるうちに内容が濃くなっちゃいましたw

今までは、いずれはこれが仕事になるかもしれないわけだし、ずっと考え込むのは作業効率が悪くて良くないことだと思ってましたけど、寧ろいわゆる「クソコード」を製品に取り込まないためのプロセスとして「ちゃんとコードを直すこと」、そのために「よく考えてみること」は最重要なんじゃないかと思いました。

☆関連商品☆

スポンサードリンク

ブログ内検索

プロフィール

ふじこlp

Author:ふじこlp
はてなブログへ移行しました。https://higechira.hatenablog.com/

ゆとりの大学生です。どれくらいゆとりかというと土曜日に通常授業を受けたことがただの一度もありません。

IBM時代のT43は観賞用となりましたが、X61は現役。
スクエアThinkPad X Series 最高です。
MacBook Pro 始めました。がやはりThinkPadに勝る打ち心地は存在しませんね。

カレンダー

11 | 2018/12 | 01
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 - - - - -

天気予報


-天気予報コム- -FC2-

フリーエリア

ブロとも申請フォーム

QRコード

QR

アクセスカウンター

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。