これまでにも何度か紹介してきた、シリコンバレーのA16Zというトップクラスのベンチャーキャピタルの気鋭のアナリスト、ベネディクト・エバンスが、「AIのバイアス」についての考察をまとめていました。 いわゆる「AIのバイアス」といえば、例えば、白人の方が黒人より多い画像データで作ったAIシステムは白人を認識するのは得意だが黒人はそうでない、といったもののように、私達にとって想像つきやすいものについつい目が行ってしまいがちです。しかし実は、私達人間には認識すらできないもの、例えば光の当たり加減や、音の領域などがバイアスとしてデータに入ってきてしまった場合におきるAIのバイアスこそが、難しい問題なのではないかとベネディクトは言います。 いつものように、鋭い考察でいろいろな角度からAIのバイアスに切り込んでいきますが、彼のエッセイがおもしろいのは、もちろん彼の分析力、クリティカル・シンキング能力が素

概要 やむを得ない事情でgitアカウントが複数あり、会社用アカウントと個人用アカウントなどを分けたいケースがあると思います。 そういったときは、会社用アカウントで作業するフォルダと個人用アカウントで作業するフォルダを分け、gitconfigの includeIf で このフォルダ配下ならこのアカウントを使うよ という設定を書いてあげるとよさげです。 ベースとなるgitconfigを作り、分けたいアカウントの数だけ[user]だけ描いたgitconfigを作ってincludeIfで参照するといい感じだと思います。 ベースgitconfig 省略 # workフォルダの時会社用gitアカウントに切り替え [includeIf "gitdir:~/project/work/"] path = ~/.gitconfig-work # otherフォルダの時は個人用アカウントを使用する [inclu

import React, { Dispatch, useContext, useReducer, useState, useCallback } from "react"; import { Route, Switch, Link } from "react-router-dom"; import styled, { createGlobalStyle } from "styled-components"; import { Action, reducer, RootState } from "./reducer"; import * as actions from "./reducer"; // RootState context export const RootContext = React.createContext<RootState>(null as any); export

ダメなライブラリ。 redux reduxはstate管理の素晴らしいライブラリだ。 世界で一番愛用され、情報量も多く、大規模システムに向いている。 しかし、react nativeを採用するのはほとんどがスタートアップだ。 学習コストが高い＋プロトタイプ制作が苦手なreduxはスタートアップにははっきり適さない。 reduxの代わりにcontext Api/MobXを使おう。Expo＋contextApi or MobX+web版のfirebaseがスタートアップでの最適解だと思う。 react-native-cli cliでなくExpoを使おう。cliはライブラリのアップデートの際に莫大な手間がかかる。要するにnativeライブラリのメンテナンスに手間がかかりすぎるので、Expoをオススメする。(スタートアップでは特に)私はcliもexpoも現在実務で使っているが、体感expoのが２倍

最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。 type Product { id: ID! name: String! relatedProducts: [Product] } type Query { produ

何を解決したいか？ Mac, Windows, Linux, iPhoneやAndroidのスマホ・タブレットとかのデバイス間でデータの転送したいことがあります。 SlackとかLineとかSkypeとかAirDropとかあっても 送りたい相手と共通して使っているサービスを探す必要とか、 GUIのソフトウェアのインストールが必要とか、 AirDropだとApple系OSである必要 があるなどの転送の障壁があって、GUIが使えないデバイスに送りたいときなどは困ってしまいます。 すでにたくさんのファイル共有系のサービスがありますが、コマンドを使ったCUIベースにあまり親切な設計なものはあまりないと思います。 そこで、上記の問題を解決するために、以下のようなファイル転送の仕組みを作りました。 他デバイス間でデータ転送ができ、 別途ソフトウェアのインストール不要で、 パイプにとても親和性が高くエン

Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob

概要 この記事では「three.js超入門」と題して、three.jsの基礎からシェーダーの利用までをやっていきます。 ターゲットは主に「canvas表現を触ったことがないフロントエンドエンジニア」を想定しているので、jsの構文などの説明は省略しています。 three.jsのバージョンは執筆時点で最新のr98を使用します。 three.js超入門 第0回 3Dコンピュータグラフィックスの基礎 three.js超入門 第1回 レンダリングまでの流れ three.js超入門 第2回 アニメーションと時間ベースでの制御 three.js超入門 第3回 マウスやスクロールでのインタラクション three.js超入門 第4回 getBoundingClientRect()を使ったDOM要素との連携 three.js超入門 第5回 シェーダー(GLSL)の基礎 three.js超入門 第6回 Shad

この記事は、KLab Engineer Advent Calendar 2018 10日目の記事です。 はじめに 今月頭の12/1から12/2にかけて、日本で唯一のデモパーティであるTokyo Demo Fest 2018が開催されました。 デモパーティをご存じではない方のために、公式サイトから引用します。 デモパーティは、コンピュータを用いたプログラミングとアートに 興味のある人々が日本中、世界中から一堂に会し、 デモ作品のコンペティション(コンポ)やセミナーなどを行います。 また、イベント開催中は集まった様々な人たちとの交流が深められます。 またデモについて詳しく知りたい方はこちらをご覧ください。 今回私は、このパーティのGLSL Graphics CompoというGLSLコードのみで映像を作って競うコンポにTraveler 2という作品を応募して1位に選んで頂きました！ #Tokyo

Help us understand the problem. What is going on with this article?

こういうことをやろうという話です。 windows の主要ファイルを wav として直接再生し鑑賞するジャンルがあると知る。どの exe の何分何秒あたりが素敵だとか議論しててついていけないと思った。 でも shell32.dll の 8:12 からの展開は結構好き。https://t.co/TfeAjPsotN — yosshin (@yosshin4004) 2015, 3月 8 mplayer は raw audio (ヘッダも何もないただデータだけの音声ファイル) を扱えるので、コマンドラインだけで雑にあらゆるファイルを音声として再生できます。 mplayer -rawaudio samplesize=2:channels=2:rate=48000 -demuxer rawaudio <filename>

0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と

最近自分はこう書いてるという例。意見が欲しい。 この記事に redux は出てこない。 参考: https://qiita.com/mizchi/items/bcb1aef8d1f14f8d0b4a 構成要素 React flow styled-components recompose 以下 SFC = Stateless Functional Component /* @flow */ import React from "react" import styled from "styled-components" import pure from "recompose/pure" type Props = {| value: string |} export default pure(function Example(props: Props) { const { value } = p

Reactがもっと広まって欲しいと思っている今日このごろ。React EuropeでJoseph Savona氏の講演でRelayについての「モヤっと」がいっきにかなり解消された気がするので、要点を本編を翻訳しながら自分なりにまとめておきます。 私の理解が誤っている可能性は十二分にありえるので、ご指摘いただければ幸いです。 はじめに ReactとFluxって組み合わせと共によく目にするのが↓の図。 矢印は一方向にしか進まないのが特徴で、わかりやすいってのがいろんなところで書かれているんですけど、 結局データをサーバからとってくるところってどうなってるの？ってのが疑問として残ります。つまり、図で表現すると↓の部分の仕組みがどうなっているかってところです。 その部分を、Instagramのようなサービスを例に説明しています。 クライアントはどのようにしてサーバからデータを取得すべきか まず、I

絵文字を扱う上で知っておくと良いかもしれないことをまとめてみました。 Ruiさんの記事を見て、「EmojiはSurrogate Pair以外にも、色々とおもしろい技術があるんですよ〜」思って書いてみました。 なお、書いた人はAndroidの人間なので、特に表記していない場合は主にAndroid上での動作のことを書いてます。 またQiita初めてなので読みにくい部分等がありましてもご容赦ください。 サロゲートペア(Surrogate Pairs) このエントリーを書くきっかけにもなったサロゲートペア。なぜこれが導入されたかの経緯は、Ruiさんのブログエントリーに譲るとして、技術的な解説をします。 サロゲートペアは、U+0000..U+FFFFに収まりきらなかった範囲のUnicodeコードポイント(U+10000..U+10FFFF)を、なんとか16bitでエンコードしようとして導入されました

材料費400円の赤外線送受信器を、1,800円のラズパイZeroに載せて、Google Homeから操作する方法を、ゼロから丁寧に解説します。 安くても高機能 むしろ市販のスマートリモコンではできない、きめ細かな操作も簡単に実現できます。（例えば こんなこと ができます。） 簡単 電子回路を作ったことのない初心者でも作れるよう、電子部品の買い方から、丁寧に説明します。 電子工作の基本 ラズパイでの電子工作が初めてなら、こちら　→　Raspberry Piの電源でLEDを1個光らせてみる - ツール・ラボ （素晴らしく丁寧な解説なので、予備知識ゼロでも理解できるはず。） ここで紹介するスマートリモコンの回路も、まずはブレッドボードを使って、半田付けをせずに試作します。 試作品をしばらく使ってみて問題がないようなら、基板に半田付けして完成させます。 半田付けが初めてなら、こちら　→　うまくいく

「Webには時代遅れで脆弱性のあるJavaScirptライブラリで溢れていることが研究により明らかに」という記事のとおり、世の中には脆弱性のあるJavaScriptライブラリを使った多くのウェブサイトが存在します。 IPAが公開している「安全なウェブサイトの作り方」には脆弱性が修正されたバージョンのライブラリを使用する。と記述があったり、「OWASP TOP10 2017 (日本語版)」にも既知の脆弱性のあるコンポーネントの使用を避けるように、と脆弱性のあるライブラリを使用しないよう注意喚起されています。 脆弱性のあるライブラリを使用しているか調べることができるRetire.jsを紹介します。 すべての脆弱性を防げる保証は無いので、あくまで自己責任でお使いください。 Retire.jsとは Retire.jsは上の画像のようにCLIなどで実行することができる脆弱性のあるJSライブラリを検出

ややお気持ち多め。 前置き 最近の個人的な考えとして、React 書く人は ReactNative 側にスキルを寄せたほうが良いのではないか、と思っている。 ReactNative の需要の高まりは凄い。最初はプロトタイピング採用だったのが、徐々にプロダクションに出始めている。今年末には新規プロジェクトの10~20%は ReactNative になるんじゃないか？という感すらある。 僕はデスクトップのブラウザは好きだけども、残念ながら、世の中の趨勢はモバイル側にある。その上でフロントエンドにロックインすることをリスクに感じている。PWAのアプリケーションも来そうではあるが、直近の需要を賄うためにやはりReactNativeに習熟しておきたい。 大事なのは、「考え方として」 ReactNative に軸足を移したほうが色々といいということだ。 Web は基本的に動きが少ない。見栄えをよくした

JavaScript Promise デザインパターン - reduce を使った可変長非同期逐次処理 , キャンセル可能なPromise など - Promise の中では throw してはならない このコードは何が表示されるだろうか？ new Promise((resolve)=>{ setTimeout(()=>{ throw new Error("foo"); resolve("bar"); }); }) .then((a)=>{ alert(a); }) .catch((err)=>{ alert(err); });

2019年7月にGitHubにマージしたブランチが自動削除される機能が入ったためこの記事は内容の非推奨です。 Automatically delete head branches of pull requests - GitHub Changelog ブランチの自動的削除を管理する - GitHub Docs 以下は古い記述 前置き マージ済のブランチは基本的に消しても問題ないので、GitHub上には進行中のブランチだけがあるきれいな状態に保ちたいところ。 PRをマージした後にブランチを消すボタンが出るんですが、チームで開発してるとどうしても消し忘れる人が1人はいるので 1CircleCIで定期的に消すようにしました 前提 GitHub CircleCI 2.0 準備 GitHubにpushするための権限が必要なので「Settings -> Checkout SSH keys」でuser