Goのslice expressionについて - Qiita
スライスの添字は 0 から始まり、 要素数-1 までになる。このsliの場合、添字は0 ~ 4となる。 slice expressionは、配列や配列へのポインタやスライスから、別のスライスを作るときに使う記法のこと。(ちなみに文字列にも使えるが、結果は文字列になる点が少し違う) https://golang.org/ref/spec#Slice_expressions こんな風に a[low : high] と書くことで別のスライスを切り出すことができる。 lowとhighはどちらも添字が基準で、 $low \leq i < high$ の範囲が切り取られる sli[0:5] とは、 $0 \leq i < 5$ の範囲を抜き出すので、つまりは 添字0~4を抜き出す意味になる sli[:3] のようにlowを省略すると0の意味になる。 $0 \leq i < 3$ と同じ。 sli[1:
MySQLで集合差を出す - Qiita
MySQL方言にはMINUSとかEXCEPTが無いので、集合の差分を表現するのが意外と面倒くさい。大抵の場合、相関サブクエリでNOT EXISTSを使ったSQLを書くことになる。 一般従業員を示すemployeeとリーダー職を示すleaderという二種類のテーブルがあるとする。 CREATE TABLE employee ( id INT NOT NULL, PRIMARY KEY(id) ); CREATE TABLE leader ( id INT NOT NULL, PRIMARY KEY(id) ); employeeにはleaderの中身も含まれているとする。さて問題。employeeではあるが、leaderではないidを洗い出したい。 employee集合からleader集合を引くことができれば、該当のid群を洗い出せる。
PHPUnitのassertArraySubset()について - Qiita
すげー便利そうに見えて、微妙に使いづらい子だな…という印象。(言いたいこと終わり) https://phpunit.de/manual/current/ja/appendixes.assertions.html 配列のアサーションの問題 例えば、ある関数の実行結果がこういう感じの配列をだとしよう。 [ [ 'name' => 'taro', 'gender' => 'male', 'updated' => '2015-08-10 12:01:13', ], [ 'name' => 'hanako', 'gender' => 'female', 'updated' => '2016-07-31 13:04:14', ], ]; 関数のテストを書くなら、↑の配列をexpectとして用意して、結果をassertEqualsで比較すればいい。 ところが、別に全部の要素を厳密に比較しなくてもいいこと
PHPで定数定義するときはdefine()よりもconstを使うべき - Qiita
<?php define('HOGE', 'hoge'); const FUGA = 'fuga'; 見て分かる通り、defineは関数であるのに対しconstは関数ではないのでconstの方が高速に処理される。 大量に定数定義したいならconstを使う方が望ましい。 その昔「定数定義を高速に行う」というためだけの関数がいくつか存在していたが、いずれも拡張モジュールのメンテナンスが止まっているようなので、今やるならconst書き換えが現実的なチューニング法なんじゃないかな。 http://php.net/manual/ja/function.apc-define-constants.php https://pecl.php.net/package/hidef defineでしかできないこと defineは関数なので、引数には式であれば何でも書くことができる。関数の実行結果を書いてもOK。
Zend FrameworkでのViewクラスの差替・拡張方法まとめ - Qiita
Zend FrameworkはデフォルトではZend_Viewというテンプレートエンジンを使用します。(正確に言うと素のPHPに足りない便利関数集といった感じ。) SmartyやTwigといったテンプレートエンジンを連携させる場合など、Zend_View以外を使いたい場合のやり方をまとめてみます。 拡張方法の選択 Zend Frameworkは拡張方法がたくさん用意されているフレームワークです。 まずはどう拡張するのかを検討 します。 Viewヘルパーをまず検討 単純な機能拡張であれば、Viewヘルパーを作れないか検討しましょう。要は「関数が足りないので増やしたい」、という場合です。 http://framework.zend.com/manual/ja/zend.view.helpers.html Viewヘルパーはこのまとめでは扱いません。標準で付属するViewヘルパーが充分高機能なの
Zend_Db_Tableをもっと手軽に使う(概要編) #ZFhimekuri - Qiita
「Zend Framework 日めくり Calendar 2012」の3日目の記事です。何となくQiitaで書いてみます。 Zend Framework でデータベースを扱う時の定番モジュールがZend_Dbです。公式のQuickStartがわかりやすいんですが、TableDataGatewayをDataMapperから使うというガチガチ厳密な使い方をしているので、「難しそう」「面倒くさそう」という印象を受けるかもしれません。 もうちょっとお手軽に、不真面目に使う書き方を考えてみます。解説を長々と書くとダレそうなので2日間に分割します。今日は概要だけ。 用語の整理 Zend_Dbについて少し解説。主要なクラスはこの３つです。 Zend_Db … DAL（PDOのWrapper） Zend_Db_Table … O/R Mapper(Table Data Gateway) Zend_Db_
Zend_Db_Tableをもっと手軽に使う (コード解説編) #ZFhimekuri - Qiita
Zend Framework 日めくりカレンダー2011の7日目、「間に合ってない」ってツッコミには土下座しつつ、Zend_Db_Tableをもっと手軽に使う(概要編) #ZFhimekuriの続き。 Githubに上げたサンプルコードの解説を書きます。 趣旨は「とにかくユルく、ActiveRecord風にZend_Db_Tableを使う」です。 1) 初期化はapplication.iniに。 データベースの接続先やパスワードをどこに書くかは開発者の悩みの種です。 素直にZend_Applicationをベースにしているアプリの場合は、application.iniに設定を書くだけでZend_Dbを初期化できます。 実際に使用するまでDBに接続しないので、実際にDBを使わないページが多くても安心です。
Zend\LogでFingersCrossedモード(問題発生時に過去ログを一気に出力) - Qiita
アプリケーションログは、何か障害が発生した時は調査の起点になりますので大事ですよね。 ロガーは通常、ログレベルを設定できて、debug用の情報などは開発環境だけ出力し、本番環境では抑制しておきます。無駄な大量のログ出力は、それなりにパフォーマンスに悪影響を与えますからね。 しかし、何かエラーが起きたときは、ログ出力が抑制されていることにより、原因がわかりにくくなってしまいます。 Monolog特有の機能であるFingersCrossedは、このジレンマを解消します。 ある特定のレベル(CRITICALなど)のログ出力を指示した瞬間、ログレベルを切り替え、過去にさかのぼってINFOなどのすべてのログを出力します。 これにより、問題が起きた時だけ詳細にログを吐くことができ、障害対応に効果を発揮します。 Monologのfingers_crossedがようやくわかった - ゆっくり*ゆっくり [
WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
コードをまとめる技術としてのイテレータとジェネレータ - Qiita
ジェネレータが5.5から入ったことで完全に空気と化した（？）PHPのイテレータを、ちょっと違う面からまとめたいと思います。 コードをまとめるということ Don't Repeat Yourself(DRY)という言葉があります。達人プログラマーという本に出てくる言葉です。 信頼性の高いソフトウェアを開発して、開発そのものを簡単に理解したりメンテナンスできるようにする唯一の方法は、DRY原則に従うことです。 「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。」 （p. 27） 端的に言えば「同じことを二度書いてはいけない」ということですね。この原則を当てはめなくてもいい例外のパターンもいくつかあるのですが。。 コードにおいて「同じことを二度書いてはいけない」を忠実に守ろうとすると、同じコードを何度も書きたくなったら、何らかの方法でそのコードを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"Accept interfaces, Return structs"が基本なのに、何でerrorはerrorで返すのか - Qiita
dockerのtmpfsオプション - Qiita
vendor/bin/phpunitの代替手段 - Qiita
PHPUnitとデータプロバイダとテストケース生成
PHPUnitの$this->assertXXXX() の別記法 - Qiita