Build Battle Saga ~Frontend~ を開催しました - build.battle.saga.jp
なんで？ バトルサーガ JP でビルドバトルの勉強会するぞ #battlesaga_jp #build_battle https://t.co/dsEhDhXAkt— ユーン 🍆 / Yuta Suzuki (@euxn23) June 21, 2019 webpack.config.js とか .eslintrc を見せ合いっこするイベントやりたい... yaesu.rc 開きたい... 人事広報におねだりしてみよ...— 統合開発環境@技術書典う15C/遅延言い訳本を頒布します (@sadnessOjisan) July 7, 2019 ふぇっ、build battleやりてぇ…— 統合開発環境@技術書典う15C/遅延言い訳本を頒布します (@sadnessOjisan) July 7, 2019 なに？ ビルドとは複雑なものであり、求めるビルドを行う過程はバトルになることが多いもの
お前らが病院いけいけ言うから行ってきてやったよ
成人の発達障害を診断してるとこってけっこう少ないんだな。ニートに唯一残された武器の時間を使い、せっせと検索した。 大概キッズ用で何度も挫折したが、まぁ暇だし探したわ。保健所?のサイトで検索できた。 見つけて予約。 せっかく予約するも、もっとあとにしてくれって言われて再挑戦。二度目に無事予約完了。 ノコノコ診察に向かう。メンタル系って行ったことないからビビった。案外キレイ。客層はやたらデブが多い。ちなみに俺もだ。 受付にいくとなんだか問診票を書かされる。 深く考えると「こう評価してほしい」みたいに考えちゃうので、なるべく考えずに書く。 しばしステイ。 看護師の子に予備診察みたいなのをされる。みっともないことを話さざるをえないけど、頑張って話す。バックレた理由とか挫折した背景とかな。 また戻ってしばし待機。 また紙を渡される。 DSM何とかっていう、精神科御用達の質問表らしい。 せっせと書く。
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
HTML5 Conference 11/25
PWA導入の成果と課題 / nikkei-pwa-html5conf2018 - Speaker Deck
HTML5 Conference 2018 https://events.html5j.org/conference/2018/11/ で発表したPWAに関するスライドです。 [日経電子版 サイト高速化とPWA対応] https://speakerdeck.com/sisidovski/nikkei-high-performance-pwa [Nikkei achieves a new level of quality and performance with their multi-page PWA] https://developers.google.com/web/showcase/2018/nikkei [「改めまして、Progressive Web Appsと申します」── Web UXの新たな基準を考える] https://html5experts.jp/uskay/25391
エンジニアキャリアにおける焦燥感との向き合い方 #BCU30_1 / #BCU30 Engineer Career
2019/07/06 の Battle Conference Under 30 2019 で話した登壇スライドです。
【書評】「実践TypeScript」のレビューに携わって - potato4d log
本日、6/26 に発売開始された吉井 健文さんの「実践TypeScript ~ BFFとNext.js&Nuxt.jsの型定義~」の執筆に、レビュアーという形で協力させていただきました。 書籍内に Vue / Nuxt.js における TypeScript の項が存在したためそこからスタートし、それ以外の部分についても一通り読んだ形です。 献本もいただいたので折角なので書評として書籍からうける印象をまとめたいと思います。 どういう本？ 『型の強化書』原作から半年間、執筆したTypeScript の📖が6/26に刊行します 【対象読者】 ・TypeScript を現場導入したい ・Vuex の型定義がつらい ・Next.js / Nuxt.js の選定で悩み中 型定義で埋め尽くした350p、Amazonで予約開始です https://t.co/iutWF3Ju5K— Takepepe (@
微妙なエンジニアにありがちなこと - プログラミング 美徳の不幸
スタートアップなのにkubernetes, Fargate等を使う PerlやPHPをろくに知らないのにdisり、GoやRustをろくに知らないのにageる CTOを名乗っているがgithubには 'react_hello_world' のようなレポジトリがいくつかあるだけ クロスプラットフォームという言葉に誘惑されがち 開発規模や体制によらず、常にTypeScriptを使おうとする React, Redux, redux-sagaなどの技術をやたら使う半面、最終的に吐き出されるjsのサイズや読み込み速度には気が回らない 技術構成にはやたらと気を使う半面、ソースコードのディレクトリ構成やフレームワークを使わない設計に頭が回らない typoが多い スター数の少ない(100未満)わけのわからないライブラリをアプリケーションのフレームワークに採用する そもそも実務経験が浅い 実務経験がSIerし
「情熱を探そう」というアドバイスはもうやめよう
2005年のスタンフォード大学の卒業スピーチで、スティーブ・ジョブスは仕事について「たまらなく好きなことを探そう (You’ve got to find what you love)」と説きました。そして彼は「まだ見つけていないのなら、探し続けよう」と続けます。言い換えれば、「情熱を傾けられる仕事を探そう」というアドバイスを、社会に出ていく学生たちに送っています。 https://news.stanford.edu/news/2005/june15/jobs-061505.html私もスティーブ・ジョブスのような起業家をゲストとして講演にお招きして、学生の皆さん向けに話をしていただくことがあります。そんなとき、学生から最も頻繁に出てくる質問は、 「やりたいことが見つからないのですが、どうすればいいでしょうか？」 というものです。起業家が来るたびに、その質問は繰り返されます。それに対して「探
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
Account Suspended
Account Suspended This Account has been suspended. Contact your hosting provider for more information.
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?
Rails Developers Meetup 2019（2019/03/22 - 23）
PromiseとCallbackの両方に対応する関数の書き方 | Tokyo Otaku Mode Blog
こんにちは。Tokyo Otaku Mode（TOM）ソフトウェアエンジニアの稲田です。 TOMが開発、運営している自社ECサイトのotakumode.comのバックエンドは現在Node.jsで動いています。その中で多数の関数が定義され利用されていますが、そのほとんどがCallbackを取るようになっています。 しかし最近、バックエンドのNode.jsのバージョンがv6.11.xにアップデートされジェネレータが使えるようになり、co + yieldの組み合わせで同期的な書き方ができるようになりました。このco + yieldで書くために、PromiseとCallbackの両方に対応した関数を書いたときの問題とその解決方法を書いておきます。 TL;DR const f = (callback = () => {}) => { const p = new Promise((resolve, r
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
IPFSについて勉強した - mizchi's blog
ipfs.io IPFS とは / BitTorrent とどう違うのか P2P の分散ファイルシステム BitTorrentがトラッカーファイルと呼ばれる単位でファイル共有を行うのに対し、IPFS は内部が別のオブジェクトを指し示すポインタ(ディレクトリ相当) or またはバイナリ(ファイル相当)のものがDAG構造をとっていて、それぞれにユニークなキーが振られている。 IPFSの内部構造は Git の内部オブジェクトと非常に似ている。分散ファイルシステムとしての Git との概念的な差はほとんどなくて、両者ともにコンテンツアドレッシング方式の Merkle DAG 構造ということができる。調べた感じ各種ツリーフォーマットの表現の差や、オブジェクトの圧縮方法が違うだけ、といっていってよさそう。 IPFSで配布する際は、URLのような名前空間に対して保存するのではなく、オブジェクトまたはその
普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
もしコンパイラを全世界で同時にうっかり削除してしまったら、元の状態に復旧できるのだろうか？｜Rui Ueyama｜note
思考実験として、全世界の人が同時に、自分の持っているコンパイラやインタープリタなどの実行ファイルをうっかり全部消してしまったとしよう。そうするとそれ以降、ソースコードが残っていても、コンパイラ自身も含めてどのようなプログラムもコンパイルできなくなってしまう。この状況から人類は元のコンピュータ文明を復旧することができるのだろうか？ 僕は結論としては、かなり簡単に復旧できると思う。ここではその手順についてちょっと考えてみよう。 コンパイラのバイナリファイルが全部消えてしまった後、復旧のために目指すべきマイルストーンは、おそらくCコンパイラを元に戻すことになるだろう。Cで書かれたプログラムはOSやコンパイラ自身を含めてたくさんあるので、そこを起点にすれば、たくさんのプログラムを芋づる式に復旧していけるからだ。 ほとんどのCコンパイラはCかC++で書かれている。最近のGCCやClangは巨大かつC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
持続可能なプロダクト開発のために - フロントエンドと新陳代謝の話 / Frontend premised on making changes
Unpublished Event
GitHub - glideapps/quicktype: Generate types and converters from JSON, Schema, and GraphQL
AWS Amplify on Twitter: "The #AWSAmplify Console is now available in our Asia Pacific (Tokyo) 🇯🇵region! https://t.co/RrpKhlHDDi https://t.co/N2QUlNfsiM"
