サーバーサイドのテンプレートエンジンに mustache を使うのはあんまよくないようだ - tokuhirom's blog
mustache は速いしいいんじゃないの? と思ったのだが､実際使ってみると微妙だ｡ 機能が少ない やはり機能がしょぼい｡それはそれでいいんだけど｡特に自分でテンプレートを記述する時というのはつまりゴリゴリと管理画面を書く時が多いんで､まあなかなか mustache だとダルい｡それなりに複雑な画面になりがちなので｡ 結局 freemarker ぐらいの機能は会ったほうが楽っぽい｡ client side のテンプレートエンジンとコンフリクトする これがでかくて｡ client side のテンプレートエンジンとマークアップがかぶってダメになることがままあり､まあなんかめんどくさいですね｡
AngularJS 嫌いな人が多い昨今について - tokuhirom's blog
最近 AngularJS 嫌いという言説が多いですが､そういうことを仰る方々は主に先鋭的な JSer のように思います｡ ただ､僕なんかの場合には､ユーザー向けの画面の構築などには AngularJS を使って書くことは最近はほとんどなく､JS を書くといえばもっぱら管理画面です｡ 管理画面の JS を書くにあたっては AngularJS way にのっかってやると非常に楽ですよね｡管理画面を書いたりする上では vue-js とかで頑張って書くと見通しが悪くなったりしますし､こった動きなどは必要ないというところで angular.js ワリといいなと思っています｡ もっといいものがあれば移りたいですが､コストをかけずに作りやすい管理画面を作るという意味ではやはり AngularJS にまだメリットがあるなあ､と思っています｡ 2.0 が出た時にこまるというのもありますが､実際は angul
MySQL Connector/J を利用するときは cacheServerConfiguration=true を設定する - tokuhirom's blog
MySQL は一般に接続コストが低いことで知られており､コネクションプーリング等しなくても使えるので便利｡ だが､Java 用の MySQL Driver であるところの MySQL Connector/J はデフォルトでは数個のクエリを接続時に発行しており､デフォルトのままでは無駄に負荷がかかる｡ デフォルトでは以下のように4つの準備クエリが発行される! どう考えてもおかしいですよね!やばいっす! 150108 9:18:11 5 Connect root@localhost on test 5 Query /* mysql-connector-java-5.1.34 ( Revision: [email protected] ) */SHOW VARIABLES WHERE Variable_name ='language' OR Variable_name = 'net_write_
LL から Java に移行した人がはまりがちなこと - tokuhirom's blog
こんにちは｡Java 初心者です｡ Java 初心者､得に LL から Java に来た人にありがちな問題について社内向けに書いたものをオープンアンドシェアさせていただきます｡ 前提として､我々は Java 8 でガンガン攻めているということをご承知おきください｡ また､自分がこの数ヶ月で｢うわー｡こうしとくべきだったのかー｣と気づいたやつをドヤ顔で語っているということにもご注意ください｡ 【追記】 対象は中規模 B2C の場合です(中規模というのは facebook より小さいという程度の意味です) 例外を握りつぶさないようにしよう Eclipse が生成する以下のようなコードをそのまま残しているケース｡ これは言うまでもなく良くないですね｡デバッグが困難になります｡ try { } catch (IOException e) { e.printStackTrace(); } Perl
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
shell script を書くときの tips 2つ(初心者向け) - tokuhirom's blog
shell script は普段さけて通りたいと願ってやまないわけですが、たまには書かないといけないことがあるので、そういうときは覚えておくと便利な tips を2つ。 autodie っぽくするset -eとすると、コマンドの実行に失敗したときにそこで実行がとまるので便利。 #!/bin/sh set -e perl -e 'die' echo SHOULD NOT REACH HEREとすると % ./hoge.sh Died at -e line 1. % echo $? 255となって、最後までいかずに死にます。 複数のコマンドを順番に実行するときに便利。 なお、以下のような挙動をするんだそうです。 ただし失敗したコマンドが until または while ループの一部である、 if 文の一部である、 && または || リストの一部である、 コマンドの返り値が ! で反転されてい
web application 開発における git のブランチ運用ルール - tokuhirom's blog
俺は普段こういう運用でやっているが、君はどうか。 社内の trac にドキュメントをかいたので、コピペしておく。git についてはカジュアルにつかってるだけなので、もっとこうしたほうがいいんじゃねえのというのがあればおしえてください。 ブランチ命名規則master 本番の deploy 用。誰かに deploy されてこまるものはいれない。stg ステージングの deploy 用iss(\d+) チケット$1 用の topic branch。master から分岐させるその他、キャンペーン関係など、おいやすくしたい者は別途名前つけてもよし。 stg の運用基本的に、開発はチケットにひもづく topic branch でおこなうので、以下のような作業フローとなる git co master git co -b issXXX # トピックブランチをきる ... # development gi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
