This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
この記事はJavaScriptの入門書として書いているjs-primerのthisに関する部分をベースにしています。 またjs-primerでは書けなかった現在時点(2018年1月1日)でのブラウザの挙動についてを加えたものです。 次の場所にjs-primer版(書籍版)のthisについての解説があります。 この記事と違って実際にコードを実行しながら読めるので、学習ソースとしては書籍版を推奨します。 書籍版: 関数とthis · JavaScriptの入門書 #jsprimer また、バグ報告やPRも直接リポジトリにして問題ありません。 asciidwango/js-primer: JavaScriptの入門書 おかしい場所を選択した状態で右下にある”Bug Report”ボタンを押せば、簡単にtypoとかのバグを報告できます。(PRでも歓迎) 前置きはこの辺までで、ここから本編。 この記
(2019年1月19日追記)こちらの内容、そろそろ書いてから1年半が経ち、現状に合わなくなっているので、アップデート版を書きました。頃合いもよくiPad Pro 11インチを購入したので、そちらで評価しました。 xckb.hatenablog.com 一応、以下の古い記事も記録として残しておきますが、内容については上記の記事の方をご覧ください。 (以下、古い記事です) さて、突然ですがiPad Pro 10.5インチの256GBセルラータイプを買ったのですよ。おまけにSmart Keyboardの英語(US)版にApple Pencilもつけました。今までiPadはmini 3を使ってきたのですが、画面は体感で倍近い印象で大きいし、Netflixを再生したりすると音響が圧倒的に違うし、まあ多少重いんだけれどもまあこれはこれでとても良いと思います。 そしてiPad mini3はWi-Fiモデ
この記事は Distributed computing Advent Calendar 2017 の 13 日目の記事です。 Kafka のブローカー間、あるいはブローカーとクライアント間の通信は、TCP 経由のバイナリプロトコルです。 それぞれの通信は API として定義されており、どういうフォーマットのリクエスト・レスポンスなのかが定められています。 API にはバージョンがあります。 ブローカーがサポートする API のバージョンを取得するには、Kafka に標準に同梱されている kafka-broker-api-versions.sh が利用できます。 kafka-broker-api-versions.sh はクラスタ内に存在するブローカーのリストと、それぞれのブローカーがサポートする API バージョンを取得します。 $ kafka-broker-api-versions.sh
(図書館学系の話題でもあるからちょっと悩んだけれど、文献読解全般に関する内容だからこちらへ) 既に日々論文をバリバリ読んでいるひとには今更な記事だろうけれど、分野ごとの違いもあって興味深かったのでざっくり記録する。 論文を大量に読む際に、頭から几帳面に読んでいると時間がどれほどあっても足りないし、後から「こんなことが書いてあった論文なんだったっけ?」という問題も発生してしまう。 研究者の皆様はMendeley などの文献管理ツールをを用いていることが多いかとは思うが、それでも論文の読み方そのものに工夫をすればインプット/アウトプットの効率が圧倒的によくなるので、やってみるにこしたことはない。 その工夫とは何かというと、論文を読むときに「特定の問いに集中して読む」というものだ。学術論文は分野ごとの違いはあれ、必ず特定の流れに従って構成されている。そこで要点のみに注目して読み、他の事項を捨てる
Kubernetes is quickly becoming the new standard for deploying and managing software in the cloud. With all the power Kubernetes provides, however, comes a steep learning curve. As a newcomer, trying to parse the official documentation can be overwhelming. There are many different pieces that make up the system, and it can be hard to tell which ones are relevant for your use case. This blog post wi
はじめに イケてるは誇張かもしれませんが社内にデザイナーがいなく、 エンジニアにランディングページを作ってと振られたときのケースを想定して ノンデザイナーでも体系的にCSSコーディングすることでそれっぽいランディングページを作成できることを目的としてます。 デザインは一朝一夕でできるものではなく、ブランディングに関わる部分の画像に関しては、商材の撮影やPhotoShopやIllustratorで専用のアイコンやロゴ画像を別途制作する必要があります。 本格的に作成する場合はやはり本職のデザイナーさんに依頼した方が良いでしょう。 (それっぽいといったのは今回はそれらのブランディングに関わる画像の作成を省いて、素材画像やCSSでごまかしているからです。) 今回はCSS Designerという仮想CSSエディターの商材を想定してランディングページを作成しました。 作ったページ全体のサンプルはこちら
Firebaseのイベントでクックパッドの某サービス様が、「うちはエンジニアはiOSエンジニアだけで、APIも3本くらいです」とおっしゃっており、「これが時代か」と感動して、いつか触ろうと思っていて、年始で時間もあるし調べて考察。 2018-01-04 追記 コメント、Twitterで返信いただき誠にありがとうございます!懸念部分はfirebaseの既存の仕組み+GAE/GCPである程度解決できそうです。また記事書きますー! よくあるチャットアプリを例にする ログインしてチャットができるアプリを作ってみる 必要な画面 ログイン画面 ログイン チャットルーム一覧画面 チャット一覧表示 最新の更新ルームを取得して、自動更新 チャット詳細画面 チャット一覧表示 チャットが来たら更新 チャット送信 もし普通にサーバ立ててやるなら API [POST] /login [POST] /logout [
あけましておめでとうございます。新年早々おもしろツイートがバズっていました。 おっ、null安全だ pic.twitter.com/RFta3RFXxu — yuga panda (@yugapanda) 2018年1月1日 これは、ネタとしてはおもしろいんですが、 Optional について良く知らないと 「 null 安全とか言っても『Optional(2018)年』 みたいな新しい問題を生んでしまうんだな。」 とミスリーディングされてしまう可能性があります。なので、 『Optional(2018)年』と表示されること自体は問題ではなく、むしろ null 安全( null safety )のために必要である 『Optional(2018)年』は確実に防ぐことができ、心配する必要はない ということをマジレスしてみます。 そもそも何が問題なのか 今回『Optional(2018)年』と表示
個人開発 Advent Calendar 2017 の三日目の記事です。 この記事は筆者が初めて作ったAndroidアプリの設計を解説します。 何分初めてなものなので問題があったら指摘をいただければ記事(とアプリ)を修正します。 ソースは [https://github.com/turanukimaru/fehs] に公開していますがリファクタリング途中なので汚いですしGitHubも初めてなので正直よくわかっていません。 概要 このアプリはゲームの戦闘結果計算ツールです。 [https://fire-emblem-heroes.com/ja/] 任天堂の出しているファイアーエムブレムヒーローズというゲームがあります。 このゲームは将棋盤上の画面で駒を動かすSLGの一種なのですが、 戦闘に乱数が絡まないので計算結果は一定である という特徴があります。 駒同士の計算結果を事前に知ることができる
Deep Learning_ Practice and Trends - final.pdf - Google ドライブ 明けましておめでとうございます、本年もよろしくお願いいたします。新年一発目の記事はただの備忘録です。 こちらは、旧知のバクフーCEO柏野さん(@yutakashino)からご紹介いただいたNIPS2017チュートリアル。 (´-`).。oO( 今年は深層学習にいい加減なことを言う人が近くにいた,らせめてNIPS2017のこのチュートリアルくらいは押さえてよ,言うことにします."Deep Learning: Practice and Trends Tutorial " https://t.co/Q23KftmdXp https://t.co/tK7mnwmgtJ たぶんこの辺りが「常識」でしょうか… )— Yuta Kashino (@yutakashino) 2018年
🎍今年初の記事です🎍 そういえばこんな機能あったなーって感じだったので記事にしてみました。 本当は今年最初の記事用意していたのですが、まだ終わってないので後ほど。。 github.com 今回は、タスクのstartとbuildに同じ変数をwebpackへ渡すために共通化したくて、量が多くなってきたのでリファクタリングしました。 手順 文字列の場合 オブジェクトの場合 配列の場合 まとめ 手順 $npm_package_にpackage.jsonに書いたkeyをつなげるとそれのvalue展開されます。 コンソール上では、展開されませんが、JS上では展開されます。 // 確認用のJS console.log(process.argv[2]); $ npm run main > node main.js $npm_package_foo bar 文字列の場合 { "foo": "bar",
rails db:reset テーブル削除 → schema.rbの情報を元に作り直す rails db:migrate:reset テーブル削除 → 作成 → db:migrateが実行される つまり、migrationファイルを作成した後にそのファイルを修正した場合はdb:resetしても反映されない! 調べてみたら、まさにまさにの情報が。 ありがとうございます! http://easyramble.com/difference-bettween-rake-db-migrate-reset.html なんだけど、気になって色々やってると新しくrails g migration AddColumnToHogeみたいに新しく作った場合でもdb:resetじゃ反映されないぞ。 って思ったのだけどschema.rbはrails db:migrateした時に更新されるっぽいので新しくファイルを作
テストの原則 テストは信頼できるものであること テストは簡単にかけること テストはかんたんに理解できること スピードを重視しないこと テストの中では過度にDRYなコードを目指さないこと テストの重要なテクニック 期待する結果は能動形で明示的に記述すること 起きて ほしい ことと、起きて ほしくない ことをテストすること 境界値テストをすること 可読性を上げるためにスペックを整理すること describe: クラスの機能に関するアウトラインを記述する。 context: 特定の状態に関するアウトラインを記述する。 before: スペック内の重複コードをきれいにするために必要不可欠。describe ブロックの中にある各 example の前(before)に実行される RSpecのセットアップ group :development, :test do gem "rspec-rail
今年一年Kubernetes on AWSをやってきて、kube-awsメンテナ目線で、「今日から、できるだけ楽に、安定して本番運用」するための個人的ベスト・プラクティスをまとめておきます。 TL;DR EKSはまだプレビュー申込の段階。実際に動くものがあるかもわからない。 EKSとkops、kube-aws、kubesprayなどは組み合わせて使うもの。代替えにはならない。 SaaSありなら分散ログ、分散トレース、リソースモニタリングはDatadogに寄せると運用が楽 istioは安心して本番運用できるフェーズではない(Service Meshが必要なら、まだLinkerdのほうがよい) アプリケーションにPrometheusエンドポイントを生やしてメトリクスを取れるようにすべき アプリケーションはOpenTracingやZipkin、Jaegerなどのトレーサを組み込み、Zipkin
React React そのものは次の記事も参照。(React 公式よりももっと低レベルなところから始める、React チュートリアル, React チュートリアル 日本語翻訳) React は State を元にバーチャルDOMを作成し、バーチャルDOMを元にDOMを生成するシステムを担うライブラリ。state の更新があった場合、その差分だけを DOM に反映することができ、パフォーマンスが良い。つまり、PC への負担が少ない。React を用いる利点のうち、一番大きなものは、状態 state と view 実際の見た目をどうするか、という「二つの問題を完全に切り分ける」ことができる。つまり、state をどう変化させるか、という問題と、state を DOMにどう反映させれるか、の2つを完全に切り分けて実装できる。 React Component React はコンポーネントと呼ばれ
技術書(訳書)を出版社から初めて刊行したのですが、その過程で経験したことなどを共有することで誰かの役に立てて貰えれば、と言うのがこの記事の趣旨になります。最近では他にも、"CSの定番教科書「Open Data Structures」を日本にも届けたい!"というプロジェクトもあり、こうした草の根の技術書の翻訳活動がもう少し日本にあってもいいのではと個人的に思っています。理系専門書に邦訳が必要なのかどうか(英語で読めばいいでしょ論)は立場が別れるところだとは思いますが、私は基本的に上記プロジェクト内の次の一文と同じ立場です。 そして、母国語でこのような入門書が読める、少なくともその選択肢があるのは望ましいことだと考えています。 なお、この記事も前の記事に引き続き、2017年に書きかけだった記事の供養です(投稿は2018年の年始)。 年末にやりたかったのですが、年始になってしまいました。。。 ど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く