「不調なWi-Fiが雨の降っている時だけなぜかつながる」謎をエンジニアが解明
久しぶりに実家に帰ったら「雨が降っている時しかWi-Fiが使えない」という現象が発生していることを知ったエンジニアのプレドラッグ・グルエフスキー氏が、原因の調査から解決するまでの経緯をブログに投稿しています。 The Wi-Fi only works when it's raining https://predr.ag/blog/wifi-only-works-when-its-raining/ グルエフスキー氏の父親もエンジニアで、自身で設立した会社を通じてオフィスビルのギガビットイーサネットから見通し内マイクロ波リンクを介した都市間接続に至るまであらゆる種類の複雑なネットワークシステムを設計・導入していました。そのため、父親から「雨が降るとWi-Fiがつながる」という呪術的思考な発言を聞いてグルエフスキー氏は驚いたとのこと。 雨はむしろ通信の品質を悪化させる原因であるため、グルエフスキ
いつか起業したいエンジニアへ - Qiita
はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章
長く活躍できるエンジニアになるためには？ 技術者として大切にしたいこと
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
エンジニア採用面接で考えたこと
昨年末に人生ではじめて面接を担当したので、考えたことを書いていきます。 大前提 面接をやるにあたって、個人的に心がけたのは「勘違いしない」ということです。 ネット上で流れてくる人事みたいな人間にはなりたくないな、と。 ただ採用する側になってみて、確かにこれは担当者を勘違いさせる魔力があるなと感じました。 良くないですね。 ただやっぱ採用って組織やチームとしてはめちゃくちゃ重要な活動なので、そこにコミットするのは大切。 特に小さな会社であればあるほど。 前提 今回の採用に関しては、iOSエンジニアの中途採用でした。 新卒採用だったらまた基準は違うと思います。 やるべきこと 面接に臨む前に、履歴書・職務経歴書は熟読しました。 SNSアカウント/Github/ポートフォリオサイトがあれば、それもサラッと見て。 面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。 書類からある程
セキュリティエンジニアを3年続けて分かったおすすめ勉強法
セキュリティエンジニアとして就職してからそろそろ3年経ちます。独断と偏見に基づき、IT初心者・セキュリティ初心者・セキュリティエンジニアの3つの時期に分け、費用対効果の良い勉強法を紹介していきたいと思います。 セキュリティエンジニアとは 「セキュリティエンジニア」という言葉は範囲が広いですが、私が今回記載する内容は脆弱性診断やペネトレーションテストに寄った内容となっています。インシデント対応やアナリスト業務などは専門ではないので、あくまで診断系の人が書いているということをご認識おきください。 そもそもセキュリティエンジニアにどのような職種が含まれるかはラックさんが分かりやすい資料を出しているのでそちらをご覧ください(サイバーセキュリティ仕事ファイル 1、サイバーセキュリティ仕事ファイル 2)。 IT初心者時代 セキュリティを学ぶ以前に基礎となるITを学ぶ時代を考えます。 学校教育 学生の場
【日本人エンジニア必携】英語命名規則の決定版 - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
勉強を負担だと感じる人がハマっている、タスク管理の罠について。 - Qiita
この記事の内容 初心者エンジニアの勉強には、タスク管理ではなく時間管理をおススメします。 勉強が負担に感じるのは、日々のノルマが原因です。 時間管理によって、勉強を負担なく続けることができます。 エンジニアの皆さん、『勉強』できていますか？ 普段から空き時間を見つけて勉強している方にとっては、それは負担になるものではないかもしれませんが、私のように向上心が低く、仕方なく勉強している人にとっては腰が重たいものですよね。 ただ、その腰の重たさは考え方（やり方）ひとつで変わるかもしれません。この記事では、私が進んで「勉強をしよう！」と思えた『時間管理』の考え方についてご紹介します。 時間管理とは？ 時間管理についてざっくり説明すると、「その時間内で、できる限り頑張る」という考え方です。学校の授業などがそうで、1コマ50分など時間が決まっていますよね。 社会人の勉強の場合、『1日1時間勉強する』な
【実話】スキル不足でフリーランスエンジニアになった末路 - みんなのシステム企画
「フリーランスエンジニアになりたいけど、スキル不足だったらどうなっちゃうんだろう」 こんな悩みはないだろうか？ 筆者はフリーランスエンジニアとして２回活動した経験がある。１回目はエンジニアを始めて３年目の時だ。そして２回目はエンジニアを始めて７年目の時だ。この２回の経験からスキルの有無によって、フリーランスエンジニアとしての活動が大きく異なることを肌身を持って実感した。 具体的には、スキル不足な状態でフリーランスになると短期的にも長期的にも厳しいということだ。逆に、スキルが十分にある状態であればフリーランスとして活動することのメリットはとても大きい。 そこで、この記事ではスキルが足りない状態で背伸びをしてフリーランスエンジニアになるとどうなるかを実体験をベースに解説する。 この記事が筆者のように辛いフリーランス活動を経験する人を減らすことに貢献できたら光栄だ。 ①すぐに契約を切られるストレ
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
Twitterのタイムライン、エンジニア的には絶対に作りたくない→ユーザーが思ってるより複雑な構成らしい
くりたしげたか（eR）🌰ニコニコ代表の人 @sigekun 栗田 穣崇 Shigetaka Kurita ぼかれびゅ部長/ニコニコ代表/合成音声栗田まろんの中の人 /ドワンゴ取締役COO/カスタムキャスト取締役/個人垢のためニコニコへのご意見ご要望は運営窓口担当@nico_nico_talk まで🙇♂️ 開発に携わった絵文字がMoMAとM＋に収蔵✨ イラスト：アルセチカ nicovideo.jp/user/9003560 くりたしげたか（eR）🌰ニコニコ代表の人 @sigekun Twitterのタイムラインはユーザーから見ると「ツイート並べてるだけでしょ？」みたいに簡単なサービスに見えるけど、エンジニア視点で見ると、作ってと言われたら断りたいほどめんどくさいしろもの 2023-07-04 11:55:46
システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
システム運用とシステム構築、どちらが先か - orangeitems’s diary
インフラエンジニアっぽい記事をたまには。 システムには、構築の時期があって、そして運用の時期が訪れる。 構築時期をあらかじめ顧客と決め、ある時期から顧客が使い続ける。使い続けている中でいろいろと変更対応は必要になるので、これを運用と言う。 構築、運用。 あまりにも相対している概念なので、システムに携わる人々は、必ず構築部門か、運用部門の二つに分けられる。 ちなみに、私は構築から運用まで全部やってきた。区切りなく全部。ただ、業務が増えていくに従い全部自分でやるのはかえって無責任ということになった。なぜなら、私がいなくなったら誰もできなくなるからだ。会社ならば、誰かが欠けても支え合えるようにしておかないと存亡の危機となる。だから、私は最近、運用を少し離れ気味になりつつある。 さて、あまり経験のない若手が、さて構築を先にやったほうがいいか。それとも運用から入った方がいいか。この議論は私が若い頃・
エンジニアのための刑事事件対策まとめ - Qiita
こんにちは。モロと申します。 実は数年前警察のお世話になり、数年裁判等をやって、昨年晴れて無罪放免となったのですが、そういえばその後どこにも情報をまとめていなかったことに気が付きました。 正直にいうとまったく気の進まない作業ですし、数年間これにかかりきりだったこともあり「わざわざまとめなくても誰でも知ってることでは……？」みたいな気持ちもあります。 とはいえ冷静に考えると大抵の人は一生関わり合いになることのない知識で、お世話になった界隈に対して何も残さないのも不義理という感じがしたため遅ればせながら筆を執らせていただきます。 はじめに 当記事は、実際に警察のお世話になり、数年間弁護士の方にご指導いただきはしたものの、あくまで法律の専門家でも何でもない一エンジニア（というか多少エンジニアリングをかじったデザイナー）によるもので、第三者による監修等もなされていません。 実体験に基づいて少しでも
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.hatenablog.com/entry/2020/08/14/101657 # 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition # 判断と決断の違いと決断のコツ https://soudai.hatenablog.com/entry/2022/01/04/151923 # Worse Is Better -
「ChatGPTの出現でプログラマーの需要はむしろ増えてくる」 ひろゆき氏が説く、これからのエンジニアリングのかたち
技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。「技育祭2023【春】」に登壇したのは、元2ちゃんねる管理人のひろゆき氏。エンジニアを目指す学生からの質問に答えました。全5回。2回目は、「ChatGPT」がエンジニアに与える影響について。前回はこちら。 酒を飲んでコードを書ける気はしない ひろゆき氏（以下、ひろゆき）：（コメントを見て）「飲酒しながらプログラミングしているんですけど、ひろゆきさんもされていますか？」ということなんですけど、僕、酒を飲んでプログラムを書いたことはたぶんないですね。 司会者：へぇ、意外ですね。なんでですか？ ひろゆき：もともと、家であまり酒を飲まないのもあるんですけど、脳のバッファー量って超重要じゃないですか。 例えば、コードをバーッと書いている時に、話しかけられたり電話がかかってきたりすると、脳の
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリングから継続
年金の味がするお米 - プログラマでありたい
煽り気味のタイトルですが、わりと真面目な話です。私の田舎の方で長らく続けてきたお米作りを止める決断がされました。それについていろいろ思う事があるので、文章として残しておくことにします。 zcf428526によるPixabayからの画像 背景の説明と止めるに至った経緯 まず登場人物の関係をぼかしたまま書くと、読んでいる人は訳がわからなくなるので差し支えのない範囲で背景を説明します。田舎と書いて実家と書かなかった理由としては、次のような感じです 私が30歳くらいの時に、兵庫県にある父方の私の伯父に養子にいって家を継ぐことになった。私の感覚としては、実家というよりおばーちゃんの家 生まれ育った家は滋賀県の大津市にあり、兄夫婦が住んでいる 実母は既に亡くなっており、実父は田舎と呼んでいる家から車で10分くらいにある旧家を継いで暮らしている 実父も40歳くらいの時に、親戚の旧家を継ぐために養子になっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai
エンジニアとしての自分とマネージャーとしての自分の狭間で、どう成長していくのか？（AWS DevDay 2023登壇資料）
