ぼくのかんがえたさいきょうのGAS開発手法2023
前提clasp の制約、Script API の考え方、Google Drive の考え方に素直に従うその条件下である程度モダンな開発環境での開発を目指す 可能ならコードは VCS で管理する（pull-req など）ドキュメントベースで共同作業に向いた手法で開発を進める特にカジュアルに始めやすい Google Apps Script は悪い意味での属人化まっしぐらになりやすい。これが長期間の業務に影響しないような、ワンショットのものなら別にそれでもよいが、これが誰かに引き継がなければいけないような状況が生まれると一気に地獄みが増してしまうので、そうなってしまう前により良い開発手法を考えておきたい。 考慮したことGAS は素朴に作ると Script 本体の構造がそれを利用する container （例えば Spreadsheet）のデータ構造などと密結合になってしまう。この状態のままコード
Clean ArchitectureとHanamiですっきりしてきた
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
dotenvで秘密情報を扱う件 〜 Ruby, PHP, PaaS, CI について 〜
.envファイルに環境変数を書いておくdotenv って何かと一言で言うと Foreman の提供している .env ファイルから環境変数をセットする機能を Foreman 環境以外でも利用できるようにしたもの。 えーと。何のこと？って感じですね。 dotenv という言葉は意味する範囲がやや曖昧なんだけど、自分の場合は「.env ファイルに sh script のように環境変数を記述しておくと、アプリが実行時に自動的に環境変数として取り込むことができる系の機能の総称」と捉えている。 で、実装がそれぞれにある。いちばん有名な Ruby バージョンだと予想通り Dotenv gem で、他の言語でも似たようなものがいくつもある。 bkeepers/dotenv なぜ.envファイルから環境変数をセットするのか環境変数から設定を取得したり環境判別用の情報を取得しようという話は決して新しい話では
Jasmineをもう少し詳しく紹介してみる
Jasmine: BDD for Javascript | Jasmine 先日プッシュした Jasmine についてもう少し掘り下げていきます。ただしテストの書き方については触れません。それは公式の情報やすでに詳しく紹介されている記事があります。 まとめJasmine は見た目だけでなく考え方も RSpec の影響を受けているよ多少遠回りでも rubygems 版の Jasmine を使うとテストが本当に自動化できるよわざわざツールを使ってテストしたいということはある程度アプリケーションとして規模が大きいとか、サイトとして規模が大きく JavaScript の数が多くなっているので、人力チェックが大変だということではないでしょうか。 規模が大きくなってきた場合は、ある程度作法（ルール）を用意してそれを守ることが安全、安心なアプリケーションの開発、作成に欠かせません。Jasmine は単に
JavaScriptをノンプログラマに教えるMEMO
まだまったくもってメモレベル。方針とか気づいたこととかごちゃ混ぜ。 jQuery前提とりあえず jQuery 前提で。宗教戦争には興味なし。小さく十分なことができ情報が豊富、と三拍子揃ったライブラリはそれほどない。 アプリケーションを書きたいプログラマは自分の好きなものを選べばよい。 JavaScriptの記述位置JavaScript（以下、JSと略記） 外部ファイルに書く基本的には HTML の </body> の上で読むこうやって書く 1, 2 は比較的簡単に説明できるが 3 は面倒なので端折る。突っ込んでくる人がいてもその人の理解のレベルを見て判断する。 JSの記述位置と実行タイミング理解する気と力のある人には説明する。 基本的に JS は書いた位置でそのまま実行されるfunction で囲めば呼び出されたタイミングで実行されるjQuery( function($) {} ); で囲
ノーフレームワークのレガシーPHPがCIに乗るまで
ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った。 正直これは感動ものだ。 今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。 有史以前PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代 当然のように PHP と HTML と SQL 混在まともなテスト環境がなかったので似た環境をどうにか作るパスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくりテスト環境用のコードと本番環境用のコードが違うオール目視 つらかった。 みなさんの予想通りバージョン管理なんてものは存在しなかった。 素朴なPHPを徐々にclassにclass になれば phpdoc を書きやすくなるいきなり実行しないようにすればテストしやすくなる これは後から気づいたんだけど、結局フロントはロクに自動テストできてない一時期 p
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
