社員旅行とか朝礼とか運動会とか、 なんで日本の会社は学校生活の醜悪なパロディをやりがちなんだろう。 特に新入社員を子供扱いする上司ってなんなのだろう。 仕事以外の部分でこんなにストレスあるんだから外資に負けるのは当然だわな。

三国志を楽しみたい、けれど三国志を知るために何がベストか分からない、という問題(?)にぶつかっている。 ■経緯 たしか曹操って三国志の登場人物だよなー程度の理解だったが、先日のKindleセールで99円だったので、『マンガで読破 三国志』を読んだ。 マンガのキングダムより後の話で、魏呉蜀があって、劉備っていいヤツそう、ってところまで理解した。 故事になっている事柄もあるし、これを機にもうちょっと三国志を把握したいなと思っている。 把握っていうのは、飲み会で三国志のエピソードになっても楽しくついていける程度と考えてほしい。 ■今考えているもの： ・レッドクリフ（映画） 全体の1エピソードだから、全体把握はできない？ ・三国志の漫画 日経電子版のCMに使われてるやつ ・三国無双シリーズ（ゲーム） 事実とifの区分けが難しそう。ただ単純にゲームとしてそこそこ楽しそう。 ・スマホゲー きっと何かし

最近、技術者の転職を支援する会社の人と酒を飲んだとき、その人が「何と言うかな、日本の企業は技術者を甘やかし過ぎのような気がするんですよ」と言い出した。意味がよく分からなかったのでポカンとしていると、その人は話を続けた。何でも「技術のことだけをやっていればよい」との条件で技術者を募集する企業が増えたそうなのだ。 技術者が技術のことだけをやっていればよいなら、夢のような職場だ。そこで「結構なことじゃないですか」と返したところ、その人は次のように答えた。「実は、企業の採用担当者から『優秀な技術者を採用するためには、技術のことだけをやっていればよいとして募集すべきだろうか』と聞かれることが増えたのですよ」。 なるほど、それなら確かに技術者を甘やかしている。そんな夢のような職場がもともとあるならともかく、優秀な技術者を採用するために、夢のような環境をこれから用意しようというのだから、どうかしている。

※この記事はJonathan Bluks氏の「10 Signs You Will Suck at Programming」を翻訳したものです。Mediumのコメント欄より翻訳の許可を頂きました。ありがとうございます。 より多くのステッカーは、より多くの成長にはなりません。 最近、RedditやQuoraで「自分がプログラマとして成功できるか、どうすれば分かりますか？」という質問をよく見かけます。キャリアチェンジを検討したり、あるいはソフトウェア開発に興味があったりするのであれば、それはごく自然な疑問です。 コンピュータに関する正式なトレーニングを受けていない場合、人々はプログラマになることに大きな心理的障壁があると思います。プログラミングが苦手であれば、あなたは自分がプログラマとして才能が無い人だと思うのは自然な考えです。もしあなたが俳優になりたいと思っていて、自分は演技が得意かどうかを疑

銀行や大手企業がウェブ上の顧客対応に用いるAIアシスタントの多くは、女性の名前を持っている。典型例としてあげられるのが、アミーやデビー、インガ、ミア、エリカといった名前だ。 「チャットボット」と呼ばれるこれらのAIアシスタントは大手企業の、顧客対応コストを削減する効果があり、保険業界や通信キャリアでの活用も拡大中だ。調査企業Juniper Researchは、銀行業界がボットの活用でコールセンターの人員を削減し、2023年までに73億ドル（約8000億円）のコストを削減すると述べた。 しかし、多くのボットに女性の名がつけられていることは、ジェンダーのステレオタイプを助長するとの見方もある。職場で女性はアシスタント的役割を果たす、という偏見を助長させるのだ。 アップルのSiriやアマゾンのAlexaなど、ほとんどのAIアシスタントは、リリース当時は女性の声が先にあり、後に男性音声バージョンが

採用担当者向けに作った社内勉強会の資料を公開します。 出せない情報だけ削って加筆修正してあります。エンジニアと採用担当者の間でコミュニケーションが生まれ、よりミスマッチがなくなるとよいですね！ https://note.mu/corocn/n/n484bbf022712 https://twitter.com/corocn

Emiko @Emiko_blossom 普段通りでケンカもしてないし嫌がらせをされたわけでもないけど、会った後に疲労感を感じたり連絡が来るだけでなんか憂鬱になったりもやもやする時は知らないうちに相手からマウンティング行為を受けているかも……ってこれ、友人よりもどうでも付き合わないといけない周りにゴロゴロいるパターン… pic.twitter.com/0BQOVv94r6 2019-03-05 08:57:10

function f() { alert('何回閉じても無駄ですよ〜') setTimeout(f) } setTimeout(f)

はじめに こんにちは、平野です。 AWS Lambdaがやっと使えるようになってきました。 私は新しい物事を理解しようと思った時、 「できるだけ最小限な構成から少しずつ要素を増やしていって、 そこから挙動を類推して確かめる」 というような調べ方でないとどうにも腑に落ちない性格のようなので、 そんな感じでLambdaも試行錯誤してみました。 Lambdaについては前から面白そうだと思いつつもなかなか手を出せずにいました。 事前の知識としては「あるイベントが起きたら、何らかのイベントを起こすもの」 ぐらいのふわっとした理解しかありませんでしたが、 私と同じ辺りの出発点からスタートする人の参考になればと思います。 最小限でLambdaを構成する ということで、できるだけ最小限の構成でLambdaを動かしてみます。 作るもの 以下のような動作で検証を行います。 究極的に最小限というわけでは無いです

・自動テスト ・ペアプログラミング あとは何だろ アジャイルは胡散臭いんだけど、メリットデメリットが理解しやすい方だと思う 追記：語弊があるな、自動テストは重要だ。TDD、XP界隈と言ったほうがいいか 追記：胡散臭いのと、不要ってのはちょい違う。必要でも胡散臭さは放てる。過大評価が近い。あと、複数人でやる方法論で胡散臭さが出がち。

やりたいこと（ユースケース）から利用パターンへ到達できるように、ユースケース主導で紹介。利用するサービスのすべての機能をを覚えなくてもやりたいこと/部分からスタートできます。実際、類似するアーキテクチャの実例が多くあることがわかります。 パターン別のテンプレートから始めてみよう!  チュートリアルで体感しよう! - いくつかのパターンはテンプレート/雛形から始めることができます。それぞれのパターンの「Template」「Sample」「Solution」のリンク先を参照ください。 - 実際に作って動かせるチュートリアルに「Tutorial」「Workshop」リンクからアクセスできます。ちょっとしたトライに費用が気にならないのもサーバーレスの良いところ。 - 各パターンの特性に合わせたエラーハンドリングの記事を拡充中。それぞれのパターンの「エラーハンドリング」リンクからご確認ください。 -

「大企業は時間を奪っている意識がない」　AIベンチャーが本音で激論、“丸投げ依頼”の次なる課題：これからのAIの話をしよう（AIベンチャー対談編）（1/4 ページ） AIベンチャーの立場で、日本企業のAI開発に物申す！　人工知能の対話エンジンなどを開発する田中潤さんと、AI開発の現場に詳しいマスクド・アナライズさんが「昔ながらの大企業でAI導入がうまくいかない理由」や「怪しいAIベンチャーを見破る方法」などについて語りつくした。 2018年ごろから、人工知能（AI）に対する過剰な期待と盛り上がりが徐々に落ち着いてきた印象です。 調査会社のガートナージャパンは、人工知能は流行期から幻滅期に差し掛かっているという見解を18年10月に発表しました。AI開発の現場で活躍している人の中にはそうした傾向を前向きに捉え、「ようやく落ち着いて話ができる環境になった」と胸をなで下ろしている人もいます。 その

はじめに プログラマがソフトウェアを作るとユーザがつきます。ユーザがそのソフトウェアを使っていて何らかの問題が発生すると「このソフトはバグってる、直して！」と言われることがままあります。それに対して「いや、仕様だから」と突っぱねられることがあります。その後お互いの意見が「バグだ！」「いいや仕様だ！」と平行線になってお互いモヤモヤのまま終わるというのはよくある話です。 なぜこういうことが起きるかというと、原因の一つは「問題」イコール「バグ」という短絡的な考え方です。とくにソフトウェアを作ったり使ったりした経験が浅い人がこうなる傾向があると推測しています。このような食い違いは「要件」「仕様」と「実装」という言葉の意味を理解していればある程度解決できます。本書はこれらの用語について実例を挙げて簡単に紹介します。 注意点 本記事では要件や仕様を定義することが前提となっていますが、とくにユーザと開発

Satellite Data Platform 宇宙×ITで 新しい価値を 創造する Tellus（テルース）は、日本発の衛星データプラットフォームです。衛星データの提供をはじめとし、データを利用した新たなビジネスを創出する環境をご用意しています。 会員登録・ログイン

最近、知人に紹介されて、船釣りを始めた。 子供の頃、多少釣りをしたことがあったが、もう数十年も前の話だ。 現在は思想も道具もアップデートされており、要するに今の私は「シロート」。 そう言えば、漫画「はじめの一歩」の主人公の実家が釣り船屋だったな……とか思い出しつつ、海に釣りに行くようになった。 釣りはつらい この話をすると、「釣りって、楽しいですか？」と聞かれることがある。 回答は無論、「楽しい」なのだが、実はそれと同じくらいの割合で「つらい」も配合されている。 例えば今の時期、洋上はめちゃくちゃ寒い。 撒き餌を仕掛けに詰めるのも、手がかじかんで、めっぽう辛い。 日陰で何時間もじっとしていると、寒くて頭がおかしくなりそうになる。 揺れる船も問題だ。手元で紐を結ぶなどの、慣れない細かい作業をしていると、船酔いしそうになる。 休もうにも、逃げ場がない。目をつぶると、余計ひどくなるし。地獄。 ま

@see <https://qiita.com/1ed873c7e9a8edd9c695d2fa438cc1ed/items/4b18c3a6178788765370/revisions/1> Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationWhat you can do with signing up

なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ

OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って

どこもかしこも妙ちくりんな図で混乱させてくるのうざい 自分で書いてみる gitなんてクソ難しいんだから、きちんと概念を理解させようとかすんなよ なぜgitが必要かバージョン管理のために必要、と言うと意味わからんと思う プログラムみたいなのは少しずつ変更していくんだ だから細かに変更の差分を管理したり、変更を戻せたりしなきゃきつい なぜgitか？他のバージョン管理との違いうるせぇgit使え そんなの来年考えろ gitの基本要素、用語branch： いきなり説明が難しいが、branchがわかればどうにかなる。 例えば、今編集しているプログラムに対して、RPGのセーブデータがあると思ってほしい。 それぞれのセーブデータがそれぞれのブランチにあたる。 セーブデータが1枠しか無いと、難しいだろ？何があるかわからない、戻ったり、試したりしたいからな。 セーブデータと少し違うのは、1個のブランチでも過去