mizchi @mizchi 「技術的には可能です」を正しく認識してもらうために、「他の開発すべて止めて数年間社運を掛けた上で成功率が1割ぐらいです」と伝えるようにしてる 2021-03-03 14:40:46

NTTドコモは、「アハモ（ahamo）」へのプラン変更で、自動廃止となるサービス、割引、特典の一覧を告知しました。 大量のドコモの純正サービスが非対応となっています。プラン変更で自動廃止となるアハモ非対応サービスは以下の通り。 あんしんパック あんしんパックホーム（携帯回線とペアの場合のみ） あんしんパックモバイル あんしん遠隔サポート いちおしパック お預かりプラス オプションパック 音声入力メール カラダのキモチ（サービス単体） カラダのキモチ（体温計セット） からだの時計ＷＭ（サービス単体） からだの時計ＷＭ（連携機器セット） キャッチホン クラウドストレージアプリ配信 クラウド容量オプション ケータイお探し　スポット契約 ケータイお探し　月額契約 ケータイお探し代行拒否 ケータイデータ お預かりサービス スピードモード つながりほっとサポート デジタル機器補償サービス（携帯回線とペ

新しいことを始めるのは難しい。 特に最初の一歩を踏み出すことが。 それは技法を知らないためだ。 独学大全のジレンマ ようやく『独学大全』を読み進めている。 独学大全――絶対に「学ぶこと」をあきらめたくない人のための５５の技法 作者:読書猿ダイヤモンド社Amazon 発売してから連日のようにおすすめツイートが流れ*1、2020年みんながオススメしたスゴ本でも堂々たる1位に輝いただけはあって、確かに良い本だ。前著『アイデア大全』『問題解決大全』も読んでいたので、評判だけということはないだろうと思っていたが、読み始めてみたら前2冊より面白い。もうちょっと早く読み始めても良かったな、というのが正直なところだ。 なぜ高い評判を得ているのに、俺は手を出すのが遅れたのか。それは「厚さ」のせいである。ソフトカバー版は788ページ*2、紹介文で「独学の百科事典」と謳うだけのことはある。しかも『独学大全』は実

しばらく辞めようと思います。 どんな勉強をしていたの 業務終了後に技術書を読んだり、資格取得（AZ-900）に取り組んだりしてました。時間が無いので寝る前とか、早めに出勤して本読んだりとか、昼休みに読んだりとかしてました。 なんのために勉強していたの 転職して仕事内容がかなり変わり、分からないことが増えました。分からないなら勉強を増やせばいい！という今思い返すとちょっと浅はかな考えです。また、インフラ女子の日常を執筆する上で中途半端なことは描きたくないという気持ちから、書くテーマについて最低1冊は読もうとしてました。ゼロトラストのテーマの時はゼロトラストネットワーク1冊とか。そりゃどえらい疲れるわぁ(´ｰ｀) なんで辞めるの 休職する程度に身体を壊したからですね。3ヶ月ほど休職して最近復職しました。 あと、この進め方で勉強してるとキリがなくて辛いからです。(´ｰ｀) 勉強しなくなった時間は

「SEO に強い HTML の書き方」というツイートがそこそこバズっていて、その内容に対して駆け出しエンジニアの方たちが「参考になった」などと称賛の声を挙げていたのを見かけて思うところがあったのでこの記事を書きました。 元ツイの概要は次の通り。 body > main > article > sectionに h1は 1 ページに 1 つ（要キーワード） 見出しタグは毎度 section で囲む ヘッダーメニューは nav で囲む 画像に適切な alt を設定する title / description を書く 階層を意識して書く div はあまり使わない 画像は p で囲む この記事は元ツイおよび元ツイの投稿者を批判する意図で書いたものではなく、あくまで挙げられている内容に対する個人的見解をまとめたものです。 正しいか正しくないかをそれぞれの項目のはじめに書いていますが、あくまで僕個人の

ITエンジニアが投票した「ITエンジニア本大賞2021」ベスト10発表。「オブジェクト指向UIデザイン」「Clean Agile」「思考法図鑑」など 「ITエンジニア本大賞」は翔泳社が主催するイベントです。ただし、対象となる書籍は出版社を問わず技術書、ビジネス書全般です。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍を投票します。 今回発表されたのは技術書部門とビジネス書部門のそれぞれ10冊。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月18日、19日に開催するオンラインイベント「Developers Summit 2021（デブサミ2021）」において、書籍の著者、編集者、翻訳者などによるプレゼン大会が開催され、特別ゲストとイベント観覧者による最終投票を経て技術書・ビジネス書の各大賞が決定されます。 技術書部門

宇野維正 @uno_kore 映画・音楽ジャーナリスト 著書「1998年の宇多田ヒカル」「小沢健二の帰還」「2010s」ほか 新刊「ハリウッド映画の終焉」 YouTube「MOVIE DRIVER」tinyurl.com/5n75ztm5 International Voter for Golden Globe Awards instagram.com/uno_kore/ 宇野維正 @uno_kore アルバム通してちゃんと聴いた。この気恥ずかしさは嫌いじゃないんだけど、このビートの単調さと音色・音圧のショボさが世間で許容されてるのはちょっと信じたがたい。少なくとも家のスピーカーで聴く音楽じゃないですね THE BOOK by YOASOBI open.spotify.com/album/1xhO0GSo… 2021-01-18 19:29:19

「USB Type-C端子には、実は表裏が存在する」という豆知識が、Twitterで話題です。どちら向きで挿しても接続できるのがType-Cの利点だけど、表か裏かで違いが出る……？ 他のUSB規格とは異なり、表裏のどちらからでも挿せるType-C端子（画像はWikipediaより） Type-C端子にはピンが2列に12ずつ配されています。基本的には同じ役割を持つピンがペアとなって点対称で配列されているため、裏返しでも接続できるわけですが、話題を呼んだツイートは「完全な対称ではない」と指摘。確かに、Type-Cの規格を確認すると、片方の役割が若干異なる、特殊なペアが1組みられます。 Type-C端子（オス側）のピン配列（画像はWikipediaより）。A2とB2のように同系統のペアが点対称形で配されているが、A5とB5のみ、B5がA5とは別の役割も担う特殊な組み合わせとなっている（B6とB7

プログラムが組めるとプログラムが教えれると思いがちだけど、教えることは別の技術です。 教えてもなかなか理解してくれないとき、プログラミングに向いてないとさえ言う人もいますが、教える側の教える技術の不足です。 教えることも技術のひとつだと気付けば、教えてもなかなか理解してくれないときに技術の不足であるということにも思い至れると思います。技術の不足であると気付けば、改善もしていけます。 そして教える技術というのは、インストラクショナルデザインという名前で系統だてて整理されています。 たとえばそのまま「インストラクショナルデザイン」など、タイトルにインストラクショナルデザインが含まれた書籍もたくさん出ています。 インストラクショナルデザイン―教師のためのルールブック 作者:島宗 理発売日: 2004/11/01メディア: 単行本 他にも、タイトルにはインストラクショナルデザインとついてないけどイ

最近「Raspberry Piはすぐ壊れる」という趣旨の話題がTL上に出てきたので複雑な心境で眺めていました。 (以下簡略化のためRaspberryPi = RPiにします) もし「RPiはすぐ壊れるから製品投入に向いてない」と思っている方がいるのであれば、その理由でRPiを切ってるのはもったいないなぁと思いこの記事を書いてみました。 カンタンに自己紹介をしておくと、某社でRPiをベースにした製品を作り「RPiはすぐ壊れないものなのか？」の検証を進めていました。今では各地で5000台以上は動いてると思います。 ざっと書いたので、あまり技術的に詳しいことは書いてませんが、読み物として楽しんでもらえれば幸いです。 （これらテストをしたのがどのバージョンのRPiなのかについては触れません。読者さんが使いたいと思ったRPiでで気になる部分をテストしてもらうことが良いと思っています） 10,000回

このブログ記事は、Advent Calender 2020, Rust 3、23日目の記事となります。自分は現在大学で教員をしていまして、セキュリティ系の研究室に所属しています。現在はセキュリティの講義を担当しており、そこでRust言語を教えているため、その内容を紹介しようと思います。 はじめに 皆さんご存知のようにソフトウェアの脆弱性は今でも大きな問題となっていますが、それを完全ではないにしろ根本から解決するための技術的手法として型システムが注目されています。型システムの考え自体は古くからありますが、最近ではRust言語が登場し、OSなどいわゆる低レイヤーなソフトウェアも型システムの恩恵を預かることができるようになってきました。SMTソルバや定理証明などと言った難しい（かつ面白い）手法でC言語やC++言語で書かれたソフトウェアを解析する方法もありますが、セキュアソフトウェアを語る上では、

www.wealthsimple.com この文章は、1969年にトロントの高校を出たばかりの、特に人生の目標もなかったトーマスの話から始まる。彼の父親は大工だったが、あいにく彼は不器用ときた。そこで母親が彼に新奇なものを勧めた。「コンピュータプログラミング……とかどう？」 トーマスはカナダの大きな銀行に入行し、1978年にプログラマーとしてのキャリアをスタートした。彼は常にパズルを解いているようでプログラミングが好きだった。彼はコードを書いては「パンチカード・オペレータ」に渡した。日に二度カードを銀行の巨大な「メインフレーム」コンピュータに食わせるが、そのコードが正しく動いているか分かるには数時間かかった。ヘマをやらかしたら、トーマスはエラー文を凝視して、COBOL のコードを書き直してやりなおしだ。 数年のうちにトーマスは COBOL が得意になり、かけがえのない何千行ものコードを書い

Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie

この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

こんにちは、imaimaiです。 年末ですね。一年の総まとめの時期に差し掛かってまいりました。私の方はというと、最近書類を整理していたところ、3年前の転職時に総まとめした社会人としてのTips集が出てきました。ものの書き方・伝え方・パワポなどツールの使い方・社内でうまく立ち回る政治の仕方などなど...色々まとまっていて、読みながら色々あったね...としばしノスタルジーに浸りました。 その中の「ものの書き方編」を読んでて「お、コイツやるな」と過去の自分に感心したのでnoteにまとめておこうと思いました。当時の私は仕事に加えプライベートでもブログを結構頑張って書いていて、ものを伝えることが多かったので、その知見がかなり溜まっていたのだと思います。(あと、内容から察するにところどころストレスも溜まっていたのだと思います。ほぼ原文と元の図のままなので、そのあたりも味わってもらえれば。笑) この頃に

はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです！ 何よりも感動したことは、 gc そのものが全て Go で書かれていて、

自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

ホーム ニュース Amazonが“有害なプレイヤー同士”をマッチングさせる技術の特許取得。暴言ユーザー同士で戦わされるゲームが生まれるか ゲームのオンラインマルチプレイにおけるマッチングシステムについて、Amazonが独自技術を特許として申請していたことが明らかになった。内容としては、有害であると判断されたプレイヤー同士をマッチングさせる仕組みになるという。海外メディアGamesIndustry.bizなどが報じている。 Amazonは「Behavior-aware Player Selection for Multiplayer Electronic Games」と題した技術を、2017年12月に米国特許商標庁に出願。今年10月20日になって特許技術として承認された。当該書類の中でAmazonは、まず現在のオンラインマルチプレイゲームの状況として、プレイヤーは自身に近いランク/スキルのプ

今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値