タグ

2016年6月6日のブックマーク (13件)

  • 私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD

    1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由

    私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
  • 【Python】いつまでprintデバッグで消耗してるの? - らっちゃいブログ

    Python を初めて間もない頃、自分も print デバッグしてました。効率の悪さを認識しつつも、IDEを導入してデバッグする方法を調べてセッティングして、という手順が面倒でずっと放置してました。 // 普段は vim で開発してます そうこうしてたら print デバッグではどうにもならないバグにぶち当たり、仕方なくデバッグポイントを置く方法を調べたわけです。するとどうでしょう。 ソースコード中に以下の一文を入れるだけではないですか。 import pdb; pdb.set_trace() たったこれだけで、上の一文を挿入した行で処理が停止し、コンソール上でステップ実行が出来るようになります。最高かよ。 個人的にですが、デバッガー起動中によく使うコマンドとしては以下です。 コマンド 説明 s(tep) ステップイン n(ext) ステップオーバー r(eturn) ステップアウト l(

    【Python】いつまでprintデバッグで消耗してるの? - らっちゃいブログ
  • Docker だらけの FRESH な動画配信プラットフォーム

    2016/06/03 AWS Summit Developers Conference DevCon-Use Case Track

    Docker だらけの FRESH な動画配信プラットフォーム
  • Scrumはじめるまえの本質的な部分の話 #agile #scrum - @i2key のBlog

    チームをスクラムにしたいのですが とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。 PO、SM、エンジニアの相互の信頼が一番大事。 信頼がポイント。それがない状態で始まると意味のない何かになりやすい。 最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。 そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕(PO)はそんな天才でもない

    Scrumはじめるまえの本質的な部分の話 #agile #scrum - @i2key のBlog
  • Go言語の並行処理デザインパターン by Rob Pike 前編 - Qiita

    少し古いですが、Rob Pikeの並行処理デザインパターンのビデオで取り上げられたコードまとめです。 オリジナルのソースコードはこちらで見れます。 Generator ジェネレータ package main import ( "fmt" "math/rand" "time" "runtime" ) func main() { runtime.GOMAXPROCS(runtime.NumCPU()) rand.Seed(time.Now().UnixNano()) c := boring("boring!") // Function returning a channel. for i := 0; i < 5; i++ { fmt.Printf("You say: %q\n", <-c) } fmt.Println("You're boring: I'm leaving.") } func

    Go言語の並行処理デザインパターン by Rob Pike 前編 - Qiita
  • Swiftzつかってみた - peroli Developer's Blog

    2016 - 06 - 03 Swiftzつかってみた MERY のサーバーサイドエンジニアの藤原です。 今回は、MERYの iOS アプリには使用していないのですが、一部で話題のSwiftzについて調べてみました。 Swiftzとは 他の 関数型言語 によくある機能を、Swiftでも使えるようにするライブラリです。 Swiftにも 関数型言語 っぽいmapやreduce、filter、flatMap等がありますが、例えばEitherはまだありません。 そういった、「他の言語だったらこう書けるのに」を解消してくれるライブラリです。 Swiftzの利点と欠点 利点としては、 上手くやりたいことと噛み合うとコードを短くスッキリと書ける コードの再利用性を上げやすくなる(部品を書きやすくなる) Swift3.0で追加されそうな機能を先取りして使える 他の 関数型言語 を覚えやすくなる 等があると

    Swiftzつかってみた - peroli Developer's Blog
  • [レポート] Docker と Amazon ECS で DevOps を進化させる #AWSSummit | DevelopersIO

    DockerAmazon ECS で DevOps を進化させる 6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016 の Develoeprs Confrence のセッション「DockerAmazon ECS で DevOps を進化させる」を聴講しました。記事はそのレポートです。 コンテナ技術である Docker と、Amazon EC2 のクラスタ上でコンテナを管理できる Amazon EC2 Container Service (ECS) を利用することで、アプリケーションとインフラという2つの密結合したライフサイクルの管理から脱出し、新しい DevOps へと向かう方法、及びその事例をいくつかご紹介します。 スピーカーは 岩永 亮介 氏(アマゾン ウェブ サービス ジャパン株式会社 技術部 メディア・エンターテインメント部

    [レポート] Docker と Amazon ECS で DevOps を進化させる #AWSSummit | DevelopersIO
  • SonarQubeでPHPのコードを静的解析する - Qiita

    2019-02-10 追記: SonarQubeではなくPHPStanで同様のことをする記事も書きました。いま個人開発ならこちらがを選ぶことも多そうです。 LaravelプロジェクトのコードをCircleCI上のPHPStanで静的解析してreviewdogにコメントしてもらう SonarQubeはオープンソースの静的解析ツール 一言で言うと「コードのダメな部分を教えてくれるやつ」です。LGPLライセンス。 下のようなこんな感じでコード品質の推移が一覧できます。また、コードごとに何が悪いのか、どう直すべきなのかを見ることができます。(画像はDrupalの解析結果) オンプレ環境で使えるのがメリットで、GitHubで個人のプロジェクトを解析するなら、各種静的解析SaaSを使うのが簡単なのでおすすめです。 PHP向け静的解析SaaSの主観的比較 (Scrutinizer, SensioLabs

    SonarQubeでPHPのコードを静的解析する - Qiita
    astk_f
    astk_f 2016/06/06
    ][静的解析][SonarQube][sourcecode]
  • GitLab CIでRailsアプリをお手軽CI開発する - Tech Inside Drecom

    Variables ビルドに必要なんだけどリポジトリに直接コミットしたくないような変数をいれておくことができます。(例:Slackのトークンやsshの秘密鍵など) ここに設定しておけばジョブ実行時に環境変数として使うことができます 3. gitlab-ci.yml をリポジトリにコミットする http://doc.gitlab.com/ce/ci/yaml/README.html や http://doc.gitlab.com/ce/ci/quick_start/README.html を参考にファイルを作ってください Railsアプリをテスト、静的解析、自動デプロイをするための設定サンプル こちらになります https://github.com/sue445/gitlab-ci-example 普通にRailsアプリをビルドするだけなら上記ファイルをコピペするだけでほぼいけると思います。

    GitLab CIでRailsアプリをお手軽CI開発する - Tech Inside Drecom
  • クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita

    「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購

    クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita
  • AppLaunchCheckerを使って初回起動を判断する - techium

    Androidアプリを作るにあたって初回起動を判断する必要があると思います。 よくあるケースとしてははじめて起動した時にチュートリアルを表示して、2回目以降はチュートリアルを出さないようにするなどの処理を考えたりするときに判断が必要になります。 一般的にはプリファレンスにデータを書き込んで1回目か2回目以降なのか判断できるようにしたりしますが、この機能を実現するAPIAndroid Support Libraryに標準で入りましたので紹介したいと思います。 実装 初回起動か2回目以降の起動かを保存するAppLaunchCheckerというのを使って機能を実現します。 AppLaunchCheckerはSupport Library v4に実装されています。 それでは使ってみましょう。 AppLaunchCheckerには2つのメソッドを持っています。 hasStartedFromLaun

    AppLaunchCheckerを使って初回起動を判断する - techium
  • HTTP Live Streamingで動画を配信してみる | DevelopersIO

    参考:動画配信プラットフォーム on AWS 2014.05.22 Amazon Data Service Japan 上図の中の HLSがHTTP Live Streamingです。 HTTPストリーミングの配信技術で、全てのプラットフォームに対応していると言えます。 (注1) QuickTime Player 10以上や、るMicrosoft Edge(Windows10)で再生可能です。InternetExplorerでは再生できません。 3 構成 HTTP Live Streamingの構成は、次の図で表現できます。 iPhoneなどのクライアントは、Webサーバに配置された動画ファイルにHTTP(HTTPS)でアクセスします(①)。 Webサーバ上の動画ファイルは、メディアセグメントファイル(.ts MPEG-2トランスポートストリームファイル)と、インデックスファイル(

    HTTP Live Streamingで動画を配信してみる | DevelopersIO
  • ソフトウェア開発で得た教訓22箇条 | POSTD

    1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い

    ソフトウェア開発で得た教訓22箇条 | POSTD