Twig 1.21.2 has just been released and contains a fix for a bug that breaks a lot of applications including recent versions of Symfony (2.3 and 2.7 latest releases; 2.3.32 and 2.7.4). Here is the full changelog: fixed variable names for the deprecation triggering code fixed escaping strategy detection based on filename added Traversable support for replace, merge, and sort deprecated support for c

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と

背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債

Chrome DevTools の Timeline タブにフレーム毎のスクリーンショットを記録/再生する機能がついています。 Canvas パーティクル 3万個 の結果です。 youtu.be Canvas/WebGL を使ったカジュアルゲームの開発やQAに活かす事ができるステキ機能ですね。 CreateJS を使っている方々は、是非試してみると良いかと。 1ヶ月ほど前から存在した機能なのですが、インパクトの割に話題になっていないようなので書いてみました。Chrome Canary で試せます。

ギルドワークスの佐々木です。 私はエンジニアですが、バックグラウンドとして人間中心設計（Human Centered Design：HCD）を学んできました。このエントリーでは、このHCDを否定するわけではなく、もう一歩進めて、User/HumanをCenterにするのではなく、CoreにしてDriveするのがよいのではないか、ということを書いてみたいと思います。 なぜ中心（Center）という言葉が使われたか 「ユーザー中心」、「人間中心」という考え方は、それぞれアメリカ、ヨーロッパが提唱した言葉でした。 これらの言葉が生まれた背景として、工業デザインとして大量生産が行われた際に、「製品中心」になってしまったことがあると考えられます。 元々、使い手と作り手は、一対一の関係でした。作り手は自然と使い手に合わせた製品を作っていたと考えられます。それが、産業革命以後、大量生産をすることで、使い

■ リーダブルコード入門 プログラム経験のある方が、リーダブルコード(※1)を書くために必要な考え方を学ぶ事ができます。 今回は、名著「リーダブルコード」の解説者である須藤先生と一緒に「3章 誤解されない名前」を読みながら、よい名前のつけ方について学びます。 ■ 対象者 プログラミング経験者で、リーダブルコードを書きたい方 変数や関数の命名に自信が持てない方 自分のコードを他の人にとっても読みやすいコードにしたい方 ■ 関数や変数で『誤解されない名前』を付けられるようになろう プログラミングを行うと、変数や関数に名前付けする機会が沢山あります。 でも名前のつけ方って、まわりの人に聞いてもなかなか明確な答えを教えてもらえませんよね？ 「うーん、自分も難しいなぁと思っているんだよねぇ」 「ケースバイケースだからなぁ」 「今回はA案の方がいいかなぁ」 でも、ベースとなる考えを持っていれば、よい名

日本年金機構の大規模な個人情報の漏洩事故は、サイバー攻撃の脅威を一般の人々に伝えてセキュリティの議論を喚起する上で、エポックメイキングな事件になった。8月下旬には内閣官房のサイバーセキュリティ戦略本部などによる調査報告書も公開され、事故の全貌が明らかになりつつある。この事件は今後のセキュリティ対策にどういう影響をもたらすか。セキュリティ技術の第一人者で、内閣官房で初代の情報セキュリティ補佐官を務めた、奈良先端科学技術大学院大学の山口英教授に話を聞いた（聞き手は山田 剛良＝日経NETWORK編集長） 日本年金機構の事件で、標的型攻撃の恐ろしさがようやく一般企業などにも知れ渡ったように感じています。サイバー攻撃に対する今の国内の認識をどう見ておられますか？ 政府の責任者や企業の経営者の人たちが、セキュリティ事故のリスクに気付くのが遅すぎたと感じている。サイバー攻撃などで起こるセキュリティ事故は

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon

READY FOR THE BATTLE? -Introduction to Live Coding-

Document for ReactMeetup#2 at 20150908

The collaborators of the Node.js project and the members of the Node.js Foundation are proud to offer v4.0.0 for general release. This release represents countless hours of hard work encapsulated in both the Node.js project and the io.js project that are now combined in a single codebase. The Node.js project is now operated by a team of 44 collaborators, 15 of which form its Technical Steering Com

僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame