注：　本稿は元はJSON Web Tokens（JWT）について書いたものですが、JWTはJavascript Object Signing and Encryption（JOSE）のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption（JOSE）を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption（JWE）、JSON Web Signatures（JWS）のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能

良いものを書きたいので指摘などは大歓迎です。 その際はコメントや編集リクエストをいただければ修正します。 大きな変更が加わるときは通知すると思います。 はじめに これまでのフロントエンドの開発には多くの問題や面倒ごとを抱えています。 その解決手段としてよくビルドツールやaltJSといったワードを目にしますが，これらがどういった目的で利用されているのかについて触れながら進めていきます。 主にパッケージ管理やビルドツールを初めて見る人向けになっているので全編通すとそれなりに長いです。 動かすまでが長めになっていますが理解してしまえば本当に必要な手順はさほど多くありません。 実際に開発を始めるために必要な準備はせいぜい1~2つのファイルを記述してコマンドを数回叩く程度なので，過度な抵抗感を持たずに読んでいただけたらなと思います。 登場するツールや技術は多くの問題を解決してくれますが，これらは飽く

元NASA所属エンジニアのMark Roberさんが、下手でも必ずブルズアイ（真ん中）に当てられるダーツボードを発明し、YouTubeで公開しました。ダーツの軌道を瞬時に予測して的が動き、むりやり真ん中へ当てさせる超絶システム。技術の無駄遣いにも程があるけどいいぞもっとやれ。 どんなに適当に投げても、届きさえすれば…… ダーツの軌跡を読んだ的が自動で移動し、真ん中へ命中させてくれる 設定の変更で、的がダーツを避ける意地悪なモードにもできるようです（動画の1分8秒ごろ） かつてNASAのJPL（ジェット推進研究所）で働いていた作者が、3年かけて開発。規定の距離からダーツが投げられると、6つのモーションキャプチャシステムが追跡します。ダーツには小さな反射板が仕込まれており、跳ね返った赤外線から位置を特定。これをもとに、システムは物理方程式を用いて軌道を計算し、ダーツの終着点を割り出します。 6

サインインした状態で「いいね」を押すと、マイページの 「いいね履歴」に一覧として保存されていくので、 再度読みたくなった時や、あとでじっくり読みたいときに便利です。

はじめに やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、この記事をかいたんだ じゃあ、注文を聞こうか。 というわけでmysqlをdisります。disるだけなので内容はありません。いいね？ mysql には罠がいっぱい そうなんですよ罠がいっぱいなんですよ奥さん。 いやこれはおそらくmysqlに限った話ではないんですけど例えばこういうの！ MySQLのチューニングなんてしたらパフォーマンス落ちるだけだし、デフォル

Apple seems to be finally getting serious about infusing generative AI into its products — both internal and external — after announcing a solitary “Transformer” model-based autocorrec

傘→防御範囲ガバガバ 合羽→蒸れる、視界が遮られがち、面倒　など多数　自転車に乗りながら傘を差す馬鹿が絶えないほど不評 レインシューズ→普通の靴の見間違うようなデザインのものも出てきたが、まだまだ長靴が主流 俺が進化を知らないだけ？

はじめに こんにちは、Python界のラファエル・ナダルです。全豪オープンテニス、盛り上がりましたね。さて、先日次のようなエントリーを立て続けに書いたんですが、「なぜAnacondaに関しての記述がないのか」という突っ込みをもらったので、参照用にメモを残しておきます。 Pythonの仮想環境構築 2017.01版 - YAMAGUCHI::weblog Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください 2017.01 - YAMAGUCHI::weblog なおこの記事の作成にあたっては @aodag に数多くのアドバイスをいただきました。この場を借りて感謝。 TL;DR condaの開発者はPyPAともっとコミュニケーションとってほしい。 前提 この記事はPythonを触り始めたばかりだけど、パッケージ管理ツール等々のスタンダードがどのようになっているかな

たいざん @tai2an けっこう反響を頂いた線画の自動着色のデモ版を公開しましたー paintschainer.preferred.tech ブログ記事はこちら↓ chainerで線画着色をwebサービスにして公開してみた qiita.com/taizan/items/7… ソースコード、学習済みモデルも公開してます pic.twitter.com/TCfOp3uZo5 2017-01-27 18:47:16

決算の要点を、すぐに配信。上場企業が発表する決算データをもとにした自動配信サービス「決算サマリー」β版

一つの会社に所属している会社員の時には気づきにくかったが、世の中には有能な人々が数多くいる。 一流の技術者。 一流のマーケターであり、ライターの彼女。 別の彼は、データ分析を専門とする。 人工知能の専門家。 保険とファイナンスのプロ。 彼らはフリーランス、経営者、会社員としてそれぞれ活躍している。 一見バラバラの経歴と所属ながら、彼らは「知識労働者」という共通点がある。自らの知識と手腕によって成果を出すことで、組織やプロジェクトに貢献している。 そして、彼らの考え方は驚くほど共通項がある。彼らが「働きたい」という会社は様々なのだが、「絶対にこの会社では働きたくない」ということはほぼ共通しているのだ。 有能な知識労働者に嫌われてしまう企業は、一流の人達を惹きつけることができない企業であり、衰退する会社だ。 奇しくもピーター・ドラッカーは1972年に既にこの状況を予言していた。※1 彼ら（知識

積ん読消化週間ということで『中久喜 健司 (2016). 科学技術計算のための Python 入門 - 開発基礎、必須ライブラリ、高速化, 技術評論社』(以下、本書) を拝読しましたのでレビューを掲載します。 科学技術計算のためのPython入門 ――開発基礎、必須ライブラリ、高速化 作者: 中久喜健司出版社/メーカー: 技術評論社発売日: 2016/09/22メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 総評 本書の最大の特徴は、Python の文法や言語仕様の解説と、Python を分析ツールとしてみたときの用法がとてもバランスよく散りばめられている点です。 本書の内容は、大きく2つに別れます。Python の言語仕様や、開発するうえでの基礎知識を得られる前半と、いわゆる PyData パッケージ群について学べる後半です。前者については、動くコードを書くこと

2016 - 12 - 10 Go言語 Web フレームワークはこれを使おう 2016年12月版 この記事は Qiita Advent Calendar 2016 Go (その2) 10日目の記事です。 Go言語の Web アプリケーションフレームワーク (以下、Web フレームワーク) は、群雄割拠の時代を経てわずかばかりまとまってきた印象があります。今回、Go言語の Web フレームワーク を選定するさいの参考になればと思い、あらためていくつかのフレームワークの特長や最近の動向をまとめました。 結論 現時点では iris または Echo の選択をおすすめします。 選定と推薦の根拠 主観 GitHub Trending, Star, Issue プロダクトでの使用経験 (Gin, Echo) 現在、 株式会社ユーリエ のプロダクト eurie Desk 開発における主たる言語として G

Mathew (Ford) Kern氏とMilko氏は先日，どちらも“アジャイルは死んだ(Agile is Dead)”と題した記事を書いた。この話題を，Kern氏は，アジャイルコンサルティングの飽和とハイプサイクルの速さに関連するものとし，Miko氏は，アジャイル活動の具現化したアプローチの速さを越えるために，アジャイルからDevOpsへと進化する必要性を説いている。 Kern氏の最初の記事のタイトルは，“Agile is Dead”そのものだ。意識的に物議を醸すような(そして皮肉な)スタンスを選んだ氏は，次のように言う。 アジャイルソフトウェア開発は死にました。実践している人はドアストップです。管理手法として用いている人はボートの錨です。波は過ぎ去りました，もう終わりです。騙されて資格を取った人は，残念ですがお金の無駄でした。 氏はさらに，マーケティングとマネジメントに関する流行とセン

追記 最新の感想も合わせてご覧ください。 jinjor-labo.hatenablog.com React界隈では結構前から「CSS in JS」と言って、雑に言うと「CSSはイケてないからJSでインラインスタイルを書いてしまえ」という話がある。（ちゃんと知りたい人はこちら） 自分も前々からCSSは変数が使えないとか名前が被るとか諸々イケてないのは同意してたんだけど、じゃあJSで書くのが良いかと言われたら「いや流石にロジック汚れるんじゃね？」とか「CSSの便利機能を捨てて平気なの？」とか色々と懐疑的だったんだけど、１～２か月書いてみたら想像以上に良かったので感想を書くことにした。 まず一番に主張したい部分を先に言うと、こう。 （誤解）JSのコードがスタイル記述で汚れる （正解）JSのコードがスタイル記述から解放される 前提 実際に書いたのはJavaScriptではなくElmなので以下は全て

先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールやフレームワークを必要とする現状はおかしい」といった、状況批判の意見が多く集まりました。 Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります。 そのため、まさか「フロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれ