タグ

2017年1月7日のブックマーク (10件)

  • Vue.js 2016年まとめ & 今後

    Vue.js 2016年まとめ & 今後この記事は、Vue.js Advent Calendar 2016の25日目最後の記事です。 フロントエンド界隈の技術、ここ最近何も進歩していないと言われてますが、Vue.js では今年2016年はいろいろとあり激動でした。 そんな Vue.js 界隈における出来事を Vue.js コアチームメンバ & Vue.js 日ユーザーグループの orgnaizer の立場でまとめつつ、最後に Vue.js の今後について少し話して、Vue.js Advent Calendar の最後を締めくくりたいと思います。 2.0 リリース!一番の大きな出来事といったら、やはり、Vue.js 2.0 のリリースでしょう! Behold! Vue 2.0 is officially out! https://t.co/OVgGo4epCO 2016年9月30日今年の4

  • xUTPの著者から教えてもらった「テストのクラフトマンシップ」 - PoohSunny's blog

    はじめに これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。 謝辞と注意点 この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros! 上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。 Unit Test Craftma

    xUTPの著者から教えてもらった「テストのクラフトマンシップ」 - PoohSunny's blog
    etakaha
    etakaha 2017/01/07
  • 2016年のサーバレスアーキテクチャ総まとめ - めもおきば

    この記事は、Serverless Advent Calendar 2016の16日分(だったはずのもの)です。 なんとかクリスマスまでには間に合ったのでお許しくださいorz まとめ AWS Lambdaの功罪で混在されがちな概念が整理されて議論されるようになった 提供されるBaaSのみを使ってリッチアプリケーションを開発する手法 フルマネージドなFaaSの実行環境 高水準コンポーネントをイベントで接続するリアクティブシステム 主要各社のFaaS実行環境が揃ってきた AWS Lambda Azure Functions (2016-11-15 GA!) IBM OpenWhisk (2016-12-14 GA! おめでとうございます!) Google Cloud Functions (2016-02-13 Alpha) 国内のニフティクラウドからも サーバレスアーキテクチャにまつわる様々な動

    2016年のサーバレスアーキテクチャ総まとめ - めもおきば
  • JavaScript でも型チェックと契約による設計で安定した開発をする - Qiita

    チーム開発をやっていると特定の処理を呼び出す際にインターフェイスを明示することがとても重要になってきます。言い換えると使い方がきちんと示されていることが最低ラインということです。ドキュメントは実際の処理と乖離しますし、各人がソースコードの処理を追わなければならないというのはチームでやっている意味がありません。 ところが JavaScript にはそういった仕組みが存在しません。どういった処理をするのかを表すための関数名は指定できますが、 JavaScript では関数を任意の名前の変数に代入できるので実はあまり役に立ちません。 といった状況にあった JavaScript ですが、昨今のツールの登場によって事情が変わってきました。 JavaScript でもインターフェイスを明示しながら開発するにはどうすればいいかを要素技術と一緒に書いていきます。

    JavaScript でも型チェックと契約による設計で安定した開発をする - Qiita
  • 大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita

    Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、記事でもその前提(RubyPHPPythonJavaScalaあたりを想定)になっています。 では、編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か?もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる

    大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita
  • 一人トランザクション技術のカレンダー | Advent Calendar 2016 - Qiita

    About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)

    一人トランザクション技術のカレンダー | Advent Calendar 2016 - Qiita
  • プロダクションで2年間Redis Clusterを運用してみて - Qiita

    TL;DR Redis Clusterで運用は当に楽になった でも、Redis 4.0は不安 Redis Clusterで一番怖いのはDisk IO 特にフェイルオーバーなどのFull Resync時 Redisとは? 高速なインメモリ型のKVS シングルスレッド 豊富なデータ構造(次ページにて詳細) 豊富な操作(次々ページにて詳細) 豊富なデータ構造 key-value型 hash型(key-field-value) set型(集合演算ができる) sorted set型(スコア付きset) 任意の型(redis modules機能) 豊富な操作 インクリメントや和集合などなど lua scriptも実行できちゃう シングルスレッドだからatomicな処理になる Redisの問題点 writeがスケールしない 気軽に停止できない サーバー再起動やバージョンアップなど Redis Clus

    プロダクションで2年間Redis Clusterを運用してみて - Qiita
  • ScalikeJDBCをAkka StreamsのSourceにする (ScalikeJDBC + Reactive Streams) - yoskhdia’s diary

    Scala Advent Calendar 2016の15日目です。 バッチアプリケーションを作ることになったので、Akka Streamsを使おうかと考えました。 Slickだと標準でstreamメソッドが用意されているため、Akka Streamsとも連携させやすいですが、ScalikeJDBCが学習コストが低くて素敵だったので、コレをAkka Streamsに組み込めないか試したエントリです。 DBMySQLを使う前提ですので、ご注意ください。 (一部Postgresも引き合いにしてますが、OracleSQL Server等は調べてません。) TL;DR github.com 2017/05/20 追記 ScalikeJDBC 3.0に公式に取り込まれました。 github.com JDBCブロッキング問題 現在、JDBCは同期インタフェースしか提供されていません。 asyncな

    ScalikeJDBCをAkka StreamsのSourceにする (ScalikeJDBC + Reactive Streams) - yoskhdia’s diary
  • 「JavaScript初級者のためのコーディングガイド」に補足を試みる - Qiita

    はじめに http://qiita.com/raccy/items/bf590d3c10c3f1a2846b を見ていたら、はてブに「理由がないから」ということがよく挙がっていたので、理由をつけてあげたら有益な内容になるかな?と思い、拙いながらも補足を試みようと思います。 【2017 1/3 15:10 追記】 元記事の前提はgulpなどを使ってminifyなども行なえる(もしくは行う目標がある)前提の様子なので、中級者以上がターゲットかなーと思いました。そのつもりで読むととてもいい記事だと思っています。 「最新のJSの書き方を覚えてあとは変換機能に任せればレガシーなJSのキツイところに向き合わなくて済みますよ?」みたいなイメージだとわかりやすいかな? ==、!= 理由 暗黙の型変換が発生して、別の型の比較が真で扱われてしまう場合があるため。 解説 サンプルコードにも出ていますが言葉足らず

    「JavaScript初級者のためのコーディングガイド」に補足を試みる - Qiita
  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様

    今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための(レスポンスボディに載せられる)標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application