先達エンジニアに学ぶ 思考の現在地 Online Conference https://findy.connpass.com/event/313119/
タイのバンコクでエンジニアリング・マネージャーをしている石坂です。 こちらの記事に触発されて、長年格闘している眼精疲労に対処するノウハウを書いてみます。 背景 かれこれ25年くらい眼精疲労と頭痛に悩まされる ひどいときは嘔吐や発熱を伴うことも 眼科・頭痛外来にも定期的に通うが、特別な異常は見つからず 低気圧や雨の日の頭痛もある 主な原因と思われるもの 高い眼圧 ドライアイ 肩こり ストレス ということで、対策・予防法としてはこのあたりになります。 眼圧を下げ、目の周りの筋肉をほぐす 肩や首まわりの筋肉をほぐす 運動・食事・睡眠、適切なストレス解消 以下に、個人的に役立ってきた対策を応急処置編と日頃の予防編に分けて記述します。 応急処置編 まずは眼精疲労と頭痛がすでに起きてしまっているケースでできることをいくつか挙げたいと思います。 目を温める 超定番ですが、これが一番よく効きます。目の周り
「技術書の読書術」を読みました 「技術書の読書術」読んだら面白かったので、後から見返せるようにまとめました。 この本はどんな本? 「探し方」「読み方」「情報発信&共有」の3つの章でコツやテクニックが書いてある 二人の技術書の著者による共著であり、考え方や思想が異なる部分もそのまま載せている 2022年10月が初版で現時点(2022年末)では比較的新しい本 各章のページ配分は以下のような感じで、表題通り「読み方」が多く書かれている 5:読み方 3:探し方 2:情報発信&共有 この感想を書いた人は? 0歳2歳を絶賛子育て中のWEBエンジニア5年目くらいの人 育休中に生活や仕事の効率を上げたいと思ってこの本を手に取った 本は読むけど、何度も見返したりアウトプットすることはあまりなかった 個人的おすすめ度:★★★★☆(4/5) GOOD:技術書大好きな著者の具体的なノウハウに触れられて刺激を受けた
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD(Domain-Driven Design)を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
ツイッターで「ソフトウェアエンジニアとしてキャリアを歩むなら、SIer はおすすめできない」と発言している方に対して、現役 SIer 社員が反論していて、ちょっとした騒ぎになっていた。 10 年間 SIer で働いた経験がある人間として、SIer で「ソフトウェアエンジニア」のキャリアを積めるかどうかについて見解を示したい。 頼むからプログラミング好きな高学歴の人は下手なネームバリューを気にしてSIerに行かないでくれ。まずSIerの研修が簡単すぎてつまらんと思うし、自分の方がプログラミングや技術分かるのに年収同じなのかって絶望するわけで。ほぼ転職する未来が待ってるんだから、最初から候補にも入れない方が良い。 — サカモト@エンジニアキャリア論 (@sakamoto_582) December 15, 2022 やはり何故かSIer叩きをしていると勘違いしてる人が大勢いるけど “SIerに
先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ/ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か?技術力が高くないとなぜ不安なのか?みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
河野と申します。2018年8月からマッハバイトで業務委託(いわゆるフリーランス)として業務に携わっており、2022年6月から、テックリード(以降、TL)という立場となりました。 TLという言葉は広く使われていますが、実際に何をするのかは、会社や環境によってさまざま。 3ヶ月の振り返りがてら、ここに一例として公開してみようと思った次第です。 TL着任以前 Join当初はRailsエンジニアとしての働きを期待されており、最初の担当はマッハバイトiOS版用に、REST APIを開発することでした。 半年少しでその業務が一段落した後は、以下のことなどを担当してきました。 Rails製アプリケーションの機能追加、Ruby、RailsのUpdate ホストOSのUpdateに伴う、deploy環境の修正や、ライブラリなどのUpdate(オンプレ環境) マイクロサービスの中心に置きたいメッセージングサー
簡単に結論 何度も調べる手間を減らすために小さな技術メモを残すのは大事 Scrapboxなら気軽に使えるようなUI/UXだからおすすめ 記事の背景 エンジニアとして働いていると、実際にコードを書いている時間よりも調査の時間が長いと思います。 新卒でエンジニアとして働き始めたときに、上司から「小さな技術メモを残す習慣をつけろ」と言われました。 いろんなツールを使って小さな技術メモをとってきたのですが、最終的にはScrapboxが一番しっくりきたので紹介したいと思い記事を書きました。 小さな技術メモとは 僕がこの記事で「小さな技術メモ」と言っているメモのイメージはこんな感じのメモです。 小さな技術メモ 内容のジャンルとしては主に以下のようなものです。 技術的な調査の結果分かった仕様 エラーの解決ログ 頻出のコードスニペット(RubyでGETリクエストするなど) 役に立った記事のブックマーク な
[いわゆる退職エントリ] Microsoft を辞めることにしました(あるいはサポートエンジニア → Product Marketing Manager になるまでなど)退職エントリ 皆さんごきげんよう。ういこうと申します。 これまで日本マイクロソフト株式会社で Azure のフロントエンド領域を中心としたサービスの Product Marketing Manager をしておりましたが、6/30 日をもって退職することとなりました。 きっと Microsoft 界隈以外では、あなたどなた?という感じだと思いますので、少し自己紹介と、退職エントリ(のようなもの)を書くことにした理由を紹介させてください。ちょっと、いや...かな~り長いので、おやつでも食べながら読むものがないなーというときや、今エンジニアなんだけど、マーケティングなど、テクニカル ロール外の職種に転換しようと思ってる、あるい
来月6月から、ソフトウェアエンジニアとして、フリーランスからIT企業の正社員に転職します。 ぼんやりと「転職をしようかな」と考えはじめたのが、昨年の12月ごろ。 とはいえ、過去一度も転職をしたことがなく、ましてや就職すらしたことがなかったので、右も左も分からぬ状態での転職活動となりました。 転職活動のやりかたは人それぞれだと思いますが、個人的にやっておくべきだったことや、やっておいてよかったことなど、さまざまな知見が得られたので、備忘録を残します。 ソフトウェアエンジニアとして転職や就職を考えている方の参考になれば嬉しいです。 なぜ就職しようと思ったのか「いつか就職しよう」と思いつつも、大学卒業してからフリーランスとしての仕事がそれなりに忙しく、ずるずるフリーランス8年目に突入してしまいました。 30歳になったとき、「30代になっても一度も会社員やらなかったら一生フリーランスだな」と自分の
オフィスアワーで1~2年目のweb/モバイルエンジニア向けに今後のキャリアや勉強方法について話す機会があった。形式としてはLTのような形ではなく、質問をいくつかもらいそれに都度答える形で進んだ。LTのような1対多の発表よりインタラクティブに相手に合った受け答えができるので良い形式だなと思った。 自分としてはキャリアについて偉そうに語れる立場ではないが、そこそこの刺さる話はできたと思うので今後のためにも要点をまとめておくことにする。 Q. エンジニアとしてのキャリア・技術遍歴を教えて! 自分は正直働いた会社は2社しかない。 2012~2014 大手 Web メディアサイトの開発 2014~現在 起業 技術遍歴。偉そうに語れるようなものではないことがお分かりいただけるだろう... 大学 4 年くらいの頃に WordPress あたりから始まり PHP や Javascript を触る 新卒入社
前回の記事でイィ感じの燃え方してイラつきはしたけど、ちゃんと調べず適当に公開したのはマズかったし、どっちみちそれまで理解が浅かったのは事実で認識してたので、それはもういいんです。 それよりもなんで、昨今はこんなにクソコメが蔓延るようになったんやろって考えてみたくなりました。エンジニアに限らず、ジャンル問わず社会的な話でもあるのですが。 社会的な風潮 要は『叩く』という行為が流行を通り越して当然になってる風潮ですね。 エンジニア関連でも、昔から技術系掲示板では、そんなことも知らんのかい!とツンツンしながらも教えてあげる文化みたいなものはありましたが、そういう『限定的な場』に自分から踏み入れない限りは、エンジニア同士の交流の多くは所属や個人サイトが判明している人だったりして、誤りや改善点があれば、スマートに指摘して、素直に受け入れる、ような流れが多かったように思います。 SNSが流行りだしてか
これまで何人も強いエンジニアと出会って、 「なんで自分はあの人と比べて何もできないんだ・・・。」と何度落ち込んだことか。 ただ、最近強いエンジニアの仕組みを理解してから落ち込むことは無くなった。 それについて書いていく。 (強いエンジニア達本人に聞いたわけではなく、観察してえられた個人の見解です) 気づき:強いエンジニアを見て落ち込む要因は2つありそう 1つは今の知識や技術力の差。 書くコードの違いだったり、成果物ができるまでの時間に差がありすぎたり、PRレビューで自分が思いもしなかったウルトラ解決策を何度も提示されて、自分の実力の無さを感じて落ち込む。 もう1つは新しいことを学ぶときの時間の差。 お互い知らない技術だったはずが、いつの間にか強いエンジニアはその技術に習熟(しているように見える)して、自分は理解不足で取り残されているという状況が発生しがち。 この時、自分には才能がないのかと
はじめに 2年半前の私は、IT系の会社に勤めている30代後半の平凡なサラリーマンでした。 その時点では、社外での発表経験なし、社外での勉強会の参加経験なし、技術記事の投稿経験なしでした。 そんな私が発信活動を始めたことで人生が変わりました。 今は凄く楽しいエンジニアライフになり、以下のような事が起きました。 複数のITエンジニア向けコミュニティに所属して楽しく交流 「Serverless LT初心者向け」というコミュニティを立ち上げて運営 Developers Summit 2020 KANSAI でベストスピーカー賞1位を受賞 ITエンジニア向けの月刊誌「Software Design」で連載記事を執筆 すべては発信活動を始めた事がきっかけでした。 発信活動を始めると素敵な事がいっぱいあると知ってもらう事で、発信活動を始めるきっかけになれば幸いです。 (長いので要点を知りたい人は太字のみ
エンジニアには「技術的な議論についていけるようになりたい」とか「自分が伸ばしたい分野の最新情報をちゃんと追いかけたい」とか悩んでいる人が多いと思う。 例に漏れず私も悩んでいて、以前からいろいろ試していたが、同僚が紹介していた「newsletterを購読する」方法が一番ためになった。 まず不足しがちな情報として、コミュニティの最新動向をキャッチアップするためにはnewsletterを購読している。 newsletterとは有志がある技術に関する最新動向をまとめて定期的に配信するメディアで、僕が購読しているものだと https://this-week-in-rust.org/ https://www.cncf.io/kubeweekly/ などがある。 大体は「<技術名> newsletter」で検索するとそれっぽいものが引っかかるのでそれをsubscribeすればよい。 まともなnewsle
みんな、ありがとう! これからは技術者として名をはせていけるよう精進するよ(Coinhive事件最高裁解説 後編):刑法感覚のないセキュリティエンジニアと技術感覚のない警察・検察との悪魔合体(1/3 ページ) Webサイトに設置した「Coinhive」が不正指令電磁的記録保管罪に当たるとされたWebデザイナーのモロさんは、2022年1月、最高裁判所で逆転無罪を勝ち取った。裁判の争点は何だったのか、同様の事件を今後起こさないために必要なことは何か、主任弁護人と弁護側証人が解説する。 WebデザイナーがWebサイトに設置した「コインハイブ(Coinhive)」が不正指令電磁的記録保管罪に当たると問われた事件は、2022年1月20日、最高裁判所で逆転無罪となった。 前編では、どれほど低い確率からの勝利であったか、そしてそれが今後どのような意味を持つのかを、主任弁護人を務めた平野敬弁護士が振り返り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く