タグ

2016年2月18日のブックマーク (15件)

  • encodeURIComponentが世界基準だと誤解してた話

    URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね?と思っていました。こんな感じに。 var finalUrl = [url, "?", encodeURIComponent("key"), "=", encodeURIComponent(

    encodeURIComponentが世界基準だと誤解してた話
  • Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ

    主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /

    Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
  • 組織にテストを書く文化を根付かせる戦略と戦術

    組織にテストを書く文化を根付かせる戦略と戦術 Feb 16, 2016 @ 日OSS推進フォーラム Read less

    組織にテストを書く文化を根付かせる戦略と戦術
  • A Tour of Go

    A Tour of Go

  • Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ

    Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
  • Goらしいコードの書き方(ミニ)

    Goらしいコードの書き方(ミニ) Go 1.6 Release Party 17 February 2016 鵜飼文敏 Fumitoshi Ukai Google Software Engineer - Chrome Infra team 巻末付録「Goらしいコードの書き方」を書きました。 Ebook is now available! 2 Go 1.6 言語仕様の変更 -> なし! Goらしいコードの書き方は基的にかわっていない。 golang.org/doc/effective_go.html github.com/golang/go/wiki/CodeReviewComments 3 Effective Go Go is a new language. Although it borrows ideas from existing languages, it has unusual

  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • なぜリアクティブは重要か #ScalaMatsuri

    "Why Reactive Matters" 日語版 2016/01/30 ScalaMatsuri 2016 by @okapies http://scalamatsuri.org/ Togetter まとめ: http://togetter.com/li/931864Read less

    なぜリアクティブは重要か #ScalaMatsuri
  • これからの Microservices

    DeNA TechCon 2016 の発表資料です。 REST と JSON の突っ込んだ話と、ちょっと Microservices の話。タイトルに偽りありです。Read less

    これからの Microservices
  • 【資料公開】DevOpsの基本

    こんにちは。@ryuzeeです。 営業でDevOpsの基の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの

    【資料公開】DevOpsの基本
    ikosin
    ikosin 2016/02/18
    “今度発売されるKanban in Actionの日本語版”
  • 人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) 日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか?というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあら

    人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
  • スキルマップ作成のすすめ

    チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★:エース、◎:得意、○:一人でできる、△:助けがあればできる、空欄:できない、・:今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果:スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます

    スキルマップ作成のすすめ
  • ドラクエ風スキルマップ - nemorineのブログ

    あるとき突然『チームのキーマンが抜ける』というイベントが発生しました! まあ会社という組織ではよくありますよね(苦笑 チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。 これもまさにゲーミフィケーションって感じですねぇ~ スキルマップを作る過程 元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ!! 以下は川口さんのオリジナルから変更したところです。 要件定義のスペシャリストとして、商人を追加。 旅芸人はマネージメントのイメージに変更 スキルの方向を上方向に変更 盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し 特性に対応するキーワードを追加 スキルマップを記述する チームメンバーに実際に

    ドラクエ風スキルマップ - nemorineのブログ
  • AWS Solutions Architect ブログ

    SA岩永です。クラウド時代になり、Blue/Greenデプロイと呼ばれる方式を取るシステムが増えてきました。ただ、日語で書かれているBlue/Greenデプロイの情報は多少古いものが多いため、特にクラウドで真価を発揮するBlue/Greenデプロイについて2015年の最後に一度まとめてみたいと思います。 以下は私の個人的な考えに基づくものであり、他にも様々な考え方があります。AWSのデプロイに関する発表でも沢山の考え方が提案されていますし、デプロイをサポートするサービスを多種多様に提供しています。1つの考え方として参考にして頂ければ幸いです。 なおこの記事は、2015年のAWS re:Inventのセッション『(DVO401) Deep Dive into Blue/Green Deployments on AWS』を参考にしています。興味のある方はSlideshareやYoutubeを

  • 世田谷区や都心23区で1歳の4月に保育園入園で預けるには実際に何をどうすればいいのか

    この合計が109点という事になります。 世田谷は自営だろうと会社員だろうと指数の付け方に差はありませんが、地域によっては自営が不利などの条件もあったりします。 ですから、パートで働いているといった勤務体系は、育休の取得が難しいと思われます。 そのため、109点にならず104点となるため、何か他で指数のポイントを稼がない限りは入園は非常に厳しくなってしまいます。 週に5日×8時間のフルタイムでの共働き、夫婦ともに今の会社で1年以上働いている、かつ育休を取得中というのが最低ラインになるのです。 ですが、今では、それだけでは厳しいというのは前回に書いた通りです。 じゃぁどうするか?という事です。 認可保育園の0歳児での4月入園を狙うのも1つの手1つの手としては、認可保育園の0歳児の4月入園に申し込んで受かることです。 1歳児で申し込もうとしていたものを、その1年前の0歳から申し込んで保育園に預け

    世田谷区や都心23区で1歳の4月に保育園入園で預けるには実際に何をどうすればいいのか