ぼくのかんがえたさいきょうのGAS開発手法2023
前提clasp の制約、Script API の考え方、Google Drive の考え方に素直に従うその条件下である程度モダンな開発環境での開発を目指す 可能ならコードは VCS で管理する（pull-req など）ドキュメントベースで共同作業に向いた手法で開発を進める特にカジュアルに始めやすい Google Apps Script は悪い意味での属人化まっしぐらになりやすい。これが長期間の業務に影響しないような、ワンショットのものなら別にそれでもよいが、これが誰かに引き継がなければいけないような状況が生まれると一気に地獄みが増してしまうので、そうなってしまう前により良い開発手法を考えておきたい。 考慮したことGAS は素朴に作ると Script 本体の構造がそれを利用する container （例えば Spreadsheet）のデータ構造などと密結合になってしまう。この状態のままコード
Feature Toggleについて調べてみた
前から何回か興味を持ってるんだけど、ちょっとまとめて調べながら思ったことをザクザク吐き出しておくよ。 今のところ考えるちょうどいい使い方いろんな使い方ができると思うんだけど、リリースサイクルの都合ではなく どんな機能が現在のプロダクトで切り替え対象となっているのかの可視化 ( admin panel )サーキットブレイカーの意味で使うのを前提にしつつ、 カナリアリリースA/Bテストにも導入していく、くらいの感じだとよさそう。 大げさな感じがするかもしれないけど、ちゃんと考えて入れないとややこしくなるだけだなと感じているので。 雑な言い方すると feature toggle って global な状態分けの if ブロックなわけで、実際、特別な記法なんかなくたって環境変数と if だけで実現可能なわけですよ。でもそれって実装側からもプロダクトオーナー側からも実態が見えにくくなるだけでいいこと
Clean ArchitectureとHanamiですっきりしてきた
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
ViewModel ComponentにModelを通じて世界の覗き窓を作る
先日来 JavaScript の ViewModel 系フレームワークで監視対象外のデータをどう扱うかというところに注目しているのだけど、これには理由があって、 VM Component の単位で影響を閉じ込めるという発想はGood単方向のデータバインディング、データフローもGoodVM Component が UI を司るのでどうしても VM Component が Model を mount するという形になり、かつモダン JS の世界では Rails 的にすべての Model が global に展開されるという考え方は NGVM Component のどこかに Model を mount しつつ「すべてのデータを監視対象とするわけではない」という形が扱いやすそう Angular で Change Detection を打ち消しまくろうとするアプローチは「気にしたくないものを網羅する
2016年に設計なんてない、そこそこの量のJavaScriptのエラーを監視して対策し始めました雑感
公開されるどこにも記録を残していないような気がするが、2016年の初めからとある事情により JavaScript のエラーをサーバに送りつけて監視サービスに送りつけてエラーの発生を知り、修正する、ということを地味にくり返していた。 そこに至る顛末と今後の分析の予定のお話。 背景これまで扱ってきたものはそこまで JS ヘビーでないものが多く、また自分で書くものはできるだけユニットテストが動くように書いていた and そもそも監視サービスが入っていなかったので、エラーのログをサーバに送るとか監視するとか、そこまで手をかけていなかった。 しかし今回の案件は初期の設計では考えてもみなかった量のカウボーイスタイル JS がコミットされしまい、要するに非常にイキのいいフレッシュなレガシーコードがてんこ盛りで動いている状態になってしまった。 （あーはい、全部ぼくがコードレビューしてリジェクトすれば防げた
JavaScriptをノンプログラマに教えるMEMO
まだまったくもってメモレベル。方針とか気づいたこととかごちゃ混ぜ。 jQuery前提とりあえず jQuery 前提で。宗教戦争には興味なし。小さく十分なことができ情報が豊富、と三拍子揃ったライブラリはそれほどない。 アプリケーションを書きたいプログラマは自分の好きなものを選べばよい。 JavaScriptの記述位置JavaScript（以下、JSと略記） 外部ファイルに書く基本的には HTML の </body> の上で読むこうやって書く 1, 2 は比較的簡単に説明できるが 3 は面倒なので端折る。突っ込んでくる人がいてもその人の理解のレベルを見て判断する。 JSの記述位置と実行タイミング理解する気と力のある人には説明する。 基本的に JS は書いた位置でそのまま実行されるfunction で囲めば呼び出されたタイミングで実行されるjQuery( function($) {} ); で囲
実はCapybaraってよく分からないんです
というか、この辺の用語がいつも混乱してとても困っていたのでいったん整理。今回のターゲットは何やら最近 JavaScript を含む Web アプリのテストでよく名前を聞く capybara-webkit からスタート。 間違ってたら突っ込んでください！ 間違ってなかったら褒めてください！ 名前capybara-webkitCapybara の driver. Capybara のテストを WebKit を通じて実行できる。WebKit と言えばみんな大好き、Google Chrome や Safari のエンジンですね。capybaraテスティングフレームワークに対して Web アプリのテストを書きやすくする語彙を提供してくれる( DSL や Driver で実装されている )。driver は default で rack_test で、JavaScript を含む場合は Seleniu
あーありがち - 最近のJavaScriptのテスティングフレームワークについて調べてみた
<< 2010/12/ 1 2 3 4 5 1. 最近のJavaScriptのテスティングフレームワークについて調べてみた 6 1. いい仕事したいじゃん 7 1. Jasmineをもう少し詳しく紹介してみる 8 9 10 11 1. 今さら始めるRails 3 12 13 14 15 16 17 18 19 20 1. 素の Ruby 環境で Fabrication 21 1. 超今さら初めてのgisty 22 23 24 25 26 27 28 1. Rinari+RhtmlでRailsのコードを書くことにした 29 30 31 >> _ 最近のJavaScriptのテスティングフレームワークについて調べてみた あるいは kanazawa.js v0.0.1 勉強会 : ATND に参加してきた。 今回はとりあえず今注目している JavaScript テスティングフレームワークの紹介と
Jasmineをもう少し詳しく紹介してみる
Jasmine: BDD for Javascript | Jasmine 先日プッシュした Jasmine についてもう少し掘り下げていきます。ただしテストの書き方については触れません。それは公式の情報やすでに詳しく紹介されている記事があります。 まとめJasmine は見た目だけでなく考え方も RSpec の影響を受けているよ多少遠回りでも rubygems 版の Jasmine を使うとテストが本当に自動化できるよわざわざツールを使ってテストしたいということはある程度アプリケーションとして規模が大きいとか、サイトとして規模が大きく JavaScript の数が多くなっているので、人力チェックが大変だということではないでしょうか。 規模が大きくなってきた場合は、ある程度作法（ルール）を用意してそれを守ることが安全、安心なアプリケーションの開発、作成に欠かせません。Jasmine は単に
JavaScript Url DispatcherとかRouterについて調べた
あるいは kanazawa.js v1.0.1 勉強会 : ATND に参加してきた。（前回と同じパターンの使い回し） なぜdispatcher（あるいは router）か実はピンときてなかったけど、なんかこういう手法があるっぽいということだけ知ってた。 pixiv Tech MeetingでpixivのJSの話をしました から辿れるスライドを見てなるほどなと思った。自分がいちばんなるほどと思ったのは WAFの不自由さ というか layout ファイルの <script> を可変にできるように仕組み用意していちいちそこに何か文字送ったりするのってめんどくさいよねというか、要するに script loading も DRY に ってことじゃないかな。もっかい整理すると layout ファイルで JavaScript のライブラリの読み込みは共通にできるでも layout ファイルの中に手を出
最近のJavaScriptのテスティングフレームワークについて調べてみた
あるいは kanazawa.js v0.0.1 勉強会 : ATND に参加してきた。 今回はとりあえず今注目している JavaScript テスティングフレームワークの紹介というかリンク集めだけ。 まとめQUnit と Jasmine について調べたよ！好きに使って！ Jasmine の使い方はまだ書くことあるんだけど疲れたからまた今度ね！書いたよ！ Jasmineをもう少し詳しく紹介してみる も読んでみて！ 自分の背景JsUnit を使って中規模なコードを書いた経験がある。普段は PHP + SimpleTest で概ね TDD で書いている。Ruby はまだ Test::Unit を使っている。RSpec に移行したいと思いながらタイミングをつかみそこねている。 テスティングフレームワークにできることまず原則は JS のみのユニットテストこれをユニットテストと呼ぶか TDD と呼ぶか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
