Web Developer の長永です。 Quipper に興味を持っているエンジニアの方に向けて、面接・面談の場で利用している会社紹介のプレゼンテーションスライドに説明をそえたドキュメントを GitHub で公開しました。 Quipper Handbook Quipper はロンドンで創業し、海外を中心にサービスを展開してきたので、日本でのサービスの知名度はいまひとつでした。そのため、面接・面談の場では時間をかけて会社やプロダクトを紹介していたのですが、会社紹介に時間がかかりすぎる傾向がありました。 面接・面談の時間は貴重なので、できればその場でしかできないことに使いたいですし、すでに Quipper のことを知っている方にとっては、同じ内容を改めて説明するのは冗長です。そこで、会社紹介の際に利用しているプレゼンテーションスライドに説明をそえたドキュメントをあらかじめお伝えし、目を通して
フォントは自由に変えられる。だから絵文字で何かを伝えるのはナンセンス。そんなことも分からなかったのか、Googleよ。
Unicodeに絵文字が多数追加されたことは、以前から批判していたのだが、やはりというか何と言うか、しょっぱい問題が起こりつつある。 macOS SierraやiOS 10でピストル絵文字🔫が水鉄砲に変わることで起こる問題。 | AAPL Ch. 絵文字はフォント次第で形が変わる。故にフォントが変わればニュアンスも変わる。自分と相手、あるいは今使っている機種と将来使う機種が同じフォントを使っているとは限らない。だからフォントを変更することで様々な問題が起きるわけである。 根本的な問題＝性質が異なるものを混ぜてしまった文字と絵は本質的に性質が違う。 文字はその見た目ではなく、文字を組み合わせた単語、単語を並べた文章によって意味を持つ。フォントが違っても、見た目の違いはあれど、文章そのものの意味は変わらない。どのようなフォントで読んでも意味は通じるのである。 ところが、絵文字はそうは行かない
投稿開発部の外村（@hokaccha）です。今回はReactについてのお話です。 ReactとSPA 最近JavaScriptやそれを取り巻くフレームワークなどの話題では、サーバ側はAPIのみを提供し、View(HTML)は全てJavaScriptで描画するような、いわゆるシングルページアプリケーション（以下SPA）についてよく語られます。 一方で、SPAを構築するにはコストがかかることも事実で、特にフロントエンドエンジニアが多くない環境では、従来通りサーバーサイドでViewを書きつつ動的な部分だけJavaScriptで処理するというアーキテクチャのほうが現実的な場合も往々にしてあります。 今回はこのような、サーバー側でHTMLを生成し、一部の動的な部分だけをReactで書くためのTipsを紹介します。 なお、基本的にサーバーサイドはRails前提ですが、RailsにおけるReactの開発
特定のAPIを利用するコマンドラインツールやサービスを書く場合はClientパッケージ（SDKと呼ばれることも多いが本記事ではClientと呼ぶ）を使うことが多いと思う．広く使われているサービスのAPIであれば大抵はオフィシャルにClientパッケージが提供されている．例えば以下のようなものが挙げられる． https://github.com/aws/aws-sdk-go https://github.com/Azure/azure-sdk-for-go https://github.com/PagerDuty/go-pagerduty https://github.com/hashicorp/atlas-go 特別使いにくい場合を除けば再実装は避けオフィシャルに提供されているものを使ってしまえばよいと思う（まともなものなら互換性などをちゃんと考慮してくれるはずなので）．一方で小さなサービ
お題「エンジニア立ち居振舞い」 同じく GitHub の通知はだいたい目を通してる。流量が多くてブラウザで開いてられないので Gmail で読み流して気になるやつだけ見に行くようにしてる。 GitHub の通知を見る専用のアプリを使っていないのは、 GitHub 以外のサービスからの通知とか、ごくわずかだけど外部の関係者とのメールとかもあってメールを一切見ないわけにはいかないので、だったらいっそ Gmail 一本にしたほうが楽だし見落としが無くて安心だと思ったからです（なので inbox zero を気合で実践してる） で、気をつけてることで、まだお題で書かれて無さそうだったのがこれです↓ 作業の進捗をチャットに逐一報告する production 環境のデータを修正するとかそういう運用系のタスクというのがけっこうあって、たいてい rake タスク + Jenkins job みたいなのを用
High Compute Queryは2017年11月に廃止になったので、この記事は過去の思い出です。 https://cloud.google.com/bigquery/docs/release-notes?hl=en#november_14_2017 今後はBillingTierが100を超えない限りは、特に料金が変わることはありません。 BillingTier100超えはかなりの無茶をしないと出てこないので、滅多に気にすることはありません。 ただ、単純なパフォーマンスチューニングとして、以下のノウハウはまだ役に立ちます。 High Compute Queryに備える！Dremelの気持ちになって考えるパフォーマンスチューニング 以下、過去の思い出話となった内容 BigQueryのQuery料金は今までどんな複雑なクエリを書いても、データを読み込んだ容量に対して料金が決定されていました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
