並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 434件

新着順 人気順

engineerの検索結果81 - 120 件 / 434件

  • 「不調な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がつながる」という呪術的思考な発言を聞いてグルエフスキー氏は驚いたとのこと。 雨はむしろ通信の品質を悪化させる原因であるため、グルエフスキ

      「不調なWi-Fiが雨の降っている時だけなぜかつながる」謎をエンジニアが解明
    • プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書

      家にパソコンがはじめて来てから30年くらい、プログラミングを始めてから20年以上が経ちました。その間、IT技術に対する愛は変わらずに、ずっと走り続けてきました。では当時の自分と今の自分で何が違うのだろうと考えてみたところ、めちゃくちゃ変わっていたのでびっくりました。本記事では何がどう変わったのか、それを見てなにを思ったかなどを書きます。 昔は次のようなこだわりがありました。 大きなものは一つの仕事をする単純で小さなツールを組み合わせて作るべし ソフトウェアは可能な限り設定可能になっていてほしいし、それを自分の好みになるまでカリカリチューニングしたい 可能な限りすべてキーボードだけで操作できるようになっていてほしい いわゆるUNIX哲学をはじめとして、いろんな本やWebサイトなどに強い影響を受けていることがよくわかります。 ところが今は次のように全然違うことを考えています。 トラブルハマった

        プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書
      • 50人ほどの小規模なコミュニティを運営する時、どういうタイプのメンバーをケアすべきなのかという話に共感集まる「ネトゲのギルドあるある」

        ばぶ@マウス🖱愛なIT系ライター @kikukaku_yki ガジェット・IT系書いてる。今年から3年ほどの人生目標は「10年後にかっこいいババアになる」です。 「おたばぶ」のばぶの方。相棒のおたよりさん( @otayori_otbb ) 飯テロがライフワーク。ネトゲもする。 Amazonのリンクは全部アソシエイト。 sampo-note.net ばぶ@マウス🖱愛なIT系ライター @kikukaku_yki ネトゲで50人ほどの小規模コミュニティを運用してたときの話。メンバーは大体5つに分類できて。 1)挨拶や呼び掛け、提案を積極的にしてくれる人 2)上記に割と乗ってくれ、発言も多い人 3)名指しで声掛けしたりお膳立てしないと乗らない人 4)とりあえずラジオにしてる人 5)空気 3~5はどう働きかけても、なにをしても、コミュニティに対して積極性を持ってはくれなかった。 ただ、4~5は別

          50人ほどの小規模なコミュニティを運営する時、どういうタイプのメンバーをケアすべきなのかという話に共感集まる「ネトゲのギルドあるある」
        • アウトプットガチ勢が作った高速記事作成フレームワーク - Qiita

          はじめに 本記事はアウトプットの心構えのカレンダー | Advent Calendar 2023の4日目の記事です こんにちは!!@Sicut_studyです! 私はアウトプットの大切さを日頃から発信しており、実際にQiitaにたくさんの記事を投稿しています そんな中で、自分なりに高速に記事としてアウトプットできるフレームワークを使っているのでそのフレームワークについて紹介していきます アウトプットの大切さ まず言っておきたいのはアウトプットは質より量です 量が増えるとだんだんと質もあがります 私は駆け出しのエンジニアの方に普段から「100本記事を書けば人生変わる」と言っています。 そもそも世の中に100本記事を書いたことのある経験をしたことがある人はごく僅かです そんなごく僅かな人になれれば絶対人生が変わります。 多くの人ができないことをやり遂げられる。しかも記事という形で目に実力が見え

            アウトプットガチ勢が作った高速記事作成フレームワーク - Qiita
          • エンジニアの人に聞きたいんですけどインターネットって誰が運営してるんですか?プロバイダにはお金払ってますがそこには払わなくてもいいんでしょうか?

            tomo @TomoEqual エンジニアの人に聞きたいんですけど、インターネットって誰が運営してるんですか?プロバイダにはお金払ってますがそこには払わなくてもいいんでしょうか 2023-10-26 07:47:07

              エンジニアの人に聞きたいんですけどインターネットって誰が運営してるんですか?プロバイダにはお金払ってますがそこには払わなくてもいいんでしょうか?
            • 2024年に読んだほうがいいエンジニアな書籍10冊+α - CloudとSREそしてキャリア本 - Lean Baseball

              Google Cloud Partner Top Engineer 2024を頂いた者です. 仕事はエンジニア系のコンサルとSRE, 趣味(と前職以前の仕事)で機械学習や生成AI*1をやっとります. この記事は当ブログの名物かつ人気シリーズである, 主に技術書を中心としたオススメ書籍(元々はPython本メイン)の紹介エントリーです. ※去年の記事はこちら. 本年のこのエントリーは, 2024年の推し本4冊 CloudおよびSREな4冊 いい感じな技術書2冊 この三本立て(+私の完全なる趣味チョイスで数冊)でご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. この記事の著者 2024年の推し技術書10冊 特に推したい4冊 クラウドストラテジー 世界一流エンジニアの思考法 仕事に役立つ新・必修科目「情報Ⅰ」 キャリアづくりの教科書 CloudおよびSREな4冊

                2024年に読んだほうがいいエンジニアな書籍10冊+α - CloudとSREそしてキャリア本 - Lean Baseball
              • 長く活躍できるエンジニアになるためには? 技術者として大切にしたいこと

                フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

                  長く活躍できるエンジニアになるためには? 技術者として大切にしたいこと
                • 働いてみないとわかりにくいIT業界の構造 SI系・プロダクト系それぞれで異なる“求められる能力”と“キャリアパス”

                  働いてみないとわかりにくいIT業界の構造 SI系・プロダクト系それぞれで異なる“求められる能力”と“キャリアパス” 総工費4億円のラボから生中継!CTOが語る、これからのエンジニアに求められる技術 #1/3 ウイングアーク1st・CTO 島澤甲氏 島澤甲氏:みなさんこんにちは。私はウイングアークでCTOをしている、島澤と申します。このセッションでは、これから技術者を目指されているみなさんに対してなにかヒントになるようなものを伝えられたらいいかなと思っています。 (スライドを示して)まずウイングアークですが、私たちは、帳票やBIと呼ばれるところでトップシェアを占めています。今日は、「このセッションは会社の宣伝をしなくてもいいよね」という話をしたら「別にかまわん」ということだったので、会社の宣伝はもうしません。気になる方はちょっとホームページを見てもらえればと思います。業績などもありますが、順

                    働いてみないとわかりにくいIT業界の構造 SI系・プロダクト系それぞれで異なる“求められる能力”と“キャリアパス”
                  • 【緑色変】算数の教養がほとんどなかったプログラマがAtCoderを4年やって緑になれた話|きりみんちゃんノート

                    こんばんみんみん。 バーチャル幼女プログラマーという肩書でインターネットをやっているきりみんちゃんというものです。 競技プログラミングのAtCoderというサービスに日々取り組んでいるんですが、この度めでたく緑レートになることが出来ました。 いわゆる色変エントリというやつです。 で、誰?3年前にこんなエントリを書いた者です。 VTuberをやったり絵を描いたりしてる社会人エンジニアです。 専門分野はAndroidでしたが、最近はフルスタックエンジニアを目指してフロントエンドやバックエンドなどをやっています。 現在のAtCoderコミュニティの中心層は理系の学生やもともと数学がかなり好きなタイプの人たちです。 一方きりみんちゃんはプログラマでありながら数学にコンプレックスがあり、それどころか小学2年までしか義務教育を受けていないため、中学、高校レベルの基礎的な数学の教養が全くありませんでした

                      【緑色変】算数の教養がほとんどなかったプログラマがAtCoderを4年やって緑になれた話|きりみんちゃんノート
                    • 【入門】基本設計

                      はじめに プロジェクトマネジメントの仕事をする際に、お客さんに提案ベースの要件定義や設計をする機会が増えてきたので、私の経験に基づいて基本設計の具体的なプロセスや考え方について、整理していきます。 以前投稿した記事の続きですが、未読でもこの記事を理解できるようになっています。 この記事の対象者 基本設計の思考プロセスを学びたい人 ビジネスサイドの要件をエンジニアサイドのシステムに落とし込む流れを学びたい人 ビジネスサイドとエンジニアサイドのコミュニケーション能力を向上させたい人 具体的な事例を通して基本設計を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要です 自分の経験に基づいた内容を言語化しています プロジェクト規模は10名から20名のシステム開発を想定しています(大規模なプロジェクトを想定していません) システム開発の全体像 今回は下記

                        【入門】基本設計
                      • WEB+DB PRESSと私

                        「大江戸Ruby会議10」での発表資料です。 https://regional.rubykaigi.org/oedo10/

                          WEB+DB PRESSと私
                        • 100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG

                          TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって

                            100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
                          • 正直いうと、一日中子供と遊ぶのが苦痛。かけがえのない時間であることは頭ではわかってるけど飽きてしまう…→この子供への無関心さが自分の両親と似てて嫌気がさす

                            宮水 @mymz_engineer 正直いうと、一日中子供と遊ぶのが苦痛。 もちろんかけがえのない時間であることは頭ではわかってる。 でも同じ絵本を繰り返し読むとか、ボールや車を転がしたり、Youtubeみてダンスしたり、すべて10分くらいで飽きてしまう、私が…。 「開発やりたいなぁ」「YouTube観たいなぁ」とか別のこと考えちゃって全力で遊べないし、この子供への無関心さが自分の両親と似てて嫌気がさすw 息子には私みたいになってほしくないからちゃんとしたいけど、ちゃんとってなんだろう…。子育てについてちゃんと学ばないとな…。 2023-08-15 22:35:37

                              正直いうと、一日中子供と遊ぶのが苦痛。かけがえのない時間であることは頭ではわかってるけど飽きてしまう…→この子供への無関心さが自分の両親と似てて嫌気がさす
                            • 英語が話せてプログラムも書けるようになったのでより就職が難しくなった件について - Qiita

                              英語が話せてプログラムも書けるようになったのでより就職が難しくなった件について 最初の記事にも書きましたが、日本を離れて10年以上、外資系の企業にて外国人と働き、または交渉事などをまとめ、何処に行ってもそれなりに不自由しない英語力を獲得し、さらにロックダウン中から2年あまり、毎日毎晩独学でコードを書き続けたことによって獲得したプログラミングスキルによりウェブアプリなどを自作できるようにまでなった訳ですが、そうして身につけた能力をフルに生かして条件の良い働き口を見つけてこましたろ と思った時に、そういった能力が身を助けるどころか、よりレッドオーシャンの荒波に我が身を晒すことになったことに気付き、愕然としてこの記事を執筆しています。 英語ができることによって競争が激化 例えば、自分は英語も話せて、プログラミングも出来ますよ となった場合、勿論グローバルな企業にて雇用されることを期待する訳ですが

                                英語が話せてプログラムも書けるようになったのでより就職が難しくなった件について - Qiita
                              • 『世界一流エンジニアの思考法』を読んでみて

                                はじめに みなさん、『世界一流エンジニアの思考法』読みましたか?(唐突) 結構 X(Twitter)で話題になっていたり、周りに読んでいる人も多かったので 年末年始のお休みに読もうと思ったら、あっという間に読了しました。 (電車の中で読んでいたら、同僚から「課題図書です」と連絡がきました。すごいタイミング) 知識の定着という意味でも、読んだことを書き出しておきたいと思います。 ※本の要約ではなく、私自身気になった点をピックアップしています。 偉大な習慣を身につけたプログラマになる 本書の「はじめに」にて 彼らはなにも全員が常人と比べて著しく頭の回転が速いわけでも、天才的記憶力を持つわけでもない。 主に「思考法」(マインドセット)が高い生産性を形づくっているのだ。 小手先のテクニックでもなければ Tips でもなく、その圧倒的なパフォーマンスは思考法から生まれているという事実。 いわゆる「一

                                  『世界一流エンジニアの思考法』を読んでみて
                                • GPT-4oの画像認識力と理解力ならいけるのではと思い手書きの仕様指示を読み込ませたら本当にコードを書き上げてくれた→「ついにコーダーが恐怖を感じる時が来たか」

                                  kmizu @kmizu A Software Engineer in Osaka (& Kyoto). Ph.D. in Engineering. Interests: Parsers, Formal Languages, etc. ツイートは所属先の見解と関係ありません.思いついたことをつぶやきます.人生を楽しく生きよう(New!) kmizu.github.io kmizu @kmizu GPT-4oの画像認識力と理解力をもってすればいけるやろと思ってやってみたら実際いけた。 ペーパープロトタイピングから最初のHTML書き起こすのにかなり使えるのでは。 つーか指示そのものを画像の中に書いたの読み取ってくれるの何か世界の壁を超えて対話してる感があって凄い #GPT4o pic.twitter.com/3XHMFg3yye 2024-05-14 12:49:41

                                    GPT-4oの画像認識力と理解力ならいけるのではと思い手書きの仕様指示を読み込ませたら本当にコードを書き上げてくれた→「ついにコーダーが恐怖を感じる時が来たか」
                                  • 開成東大卒の「天才AIエンジニア」が都知事選出馬…オードリー・タンに背中を押されて決めた「圧倒的危機感」と、ヤバすぎるリアル(現代ビジネス編集部) @gendai_biz

                                    開成東大卒の「天才AIエンジニア」が都知事選出馬…オードリー・タンに背中を押されて決めた「圧倒的危機感」と、ヤバすぎるリアル 東大卒AIエンジニア・起業家・SF作家。 そんな異色の経歴を持つ東京都知事選候補が、出馬の表明と同時に知識人からの注目を集めている。 安野貴博氏、33歳。 「テクノロジーで誰も取り残さない東京へのアップデート」などユニークな政策を掲げる彼は、一体どんな人物なのだろうか。 取材を通じて、驚くべき経歴と出馬にかける思いが明らかになってきた。 9歳の頃、独学でプログラミングを学ぶ まずは「天才AIエンジニア」と呼ばれるに至る経歴から見てみよう。 安野氏は9歳の頃、独学でプログラミングを始め、17歳にして初めてのWebサービスをリリース。未来予測の確率論「マルコフ連鎖」をベースに開発されたもので、すでに“超高校級”のエンジニアだったことがうかがい知れる。 開成高校を卒業後は

                                      開成東大卒の「天才AIエンジニア」が都知事選出馬…オードリー・タンに背中を押されて決めた「圧倒的危機感」と、ヤバすぎるリアル(現代ビジネス編集部) @gendai_biz
                                    • マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について - yo-log

                                      Engineering Manager Advent Calendar 2023 7日目の記事です。 結論ファーストで書きます マネージャーは答えを持っていません。 大事なことなのでもう一度言います。 持っていません。 この問題ってそもそもなに? 細かくみてみましょう。 マネージャーに全てを決められたくない マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。 ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck こちらのスライドにあるような「私考える人」的な動きになっているマネー

                                        マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について - yo-log
                                      • IT業界でストレスなく働くには - Qiita

                                        はじめに ITエンジニアのみなさんこんにちは。 今日はIT業界でストレスなく働くということについて考えます。 GPT先生にお題を頂いてそれぞれコメントしていきます。 状況への適応の困難さ IT業界で最も多く発生しているのはこの要因かと思います。 ITエンジニアはSESなどで時間いくらで切り売りしている時給労働者ですが、簡単にはできない技術を提供することで高い単価を頂く仕事になっています。 学生さんから社会人になった人には分かりにくいですが、一定の期間内に一定の成果を出すといった点がコンビニのバイトとは大きく異なります。 現実の状況や要求が個人の能力や資源を超えている場合、適応することが難しくなります。このような状況では、ストレスが生じやすくなります。 誰にでも簡単にはできない技術 はマニュアル化されておらず、自分で状況を判断して適切な結果を出していく仕事となりますが、それができないとすると

                                          IT業界でストレスなく働くには - Qiita
                                        • LLMのプロンプト技術まとめ - Qiita

                                          現在,34個掲載(一部執筆途中) Xのアカウント@fuyu_quantでも技術系の投稿をしているのでよかったらフォローしてください! はじめに 今回はすぐに使えそうなプロンプトの工夫やフレームワークについて有名なものをまとめました.LMの出力の精度向上に役立てられればと思います. 論文があるものについてはarXivに最初に投稿された順番で掲載しています. 論文で精度向上が確認されているのは英語での検証がほとんどであるため,日本語で改善されるかは分かりません. 全てのLLM(GPT-4,Llama2,...)で精度が改善するとは限りません. ※記事に誤り等ありましたらご指摘いただけますと幸いです. 以下の記事では敵対的プロンプト技術をまとめています! 目次 Zero-shot prompting Few-shot prompting 2021年〜 Generated Knowledge Pr

                                            LLMのプロンプト技術まとめ - Qiita
                                          • エンジニアが株式会社作ったログ

                                            この記事を読んだ方から有益な情報をたくさんいただいたので追記している。 特定創業支援等事業の認定 法人設立ワンストップサービス gBizID 自分でやっていないものについては各項目で明記している。 なぜ作ったのか? 自分の興味があった教育分野において、実際にやってみて自ら経験を積み、社会に役立つようなことがやりたいと思ったため。 あと、長くサラリーマンをやって、矛盾している組織が許せない性分だとわかったので、じゃあ自分で組織を作ってみようという単純な発想による。できるだけ矛盾していない組織を作ろうと目指しているが、やらずに文句だけ言うのはフェアでない、という意味合いもある。 フローチャート やることが多く、時系列がわかりづらかったのでフローチャートを書いてみた。 週一で動いた場合、 3 ヶ月ほどかかる。また、灰色の枠は実施していない。 経費について 登記前にかかった費用はすべて創立費、登記

                                              エンジニアが株式会社作ったログ
                                            • 30代からプログラミングを本格的に始めたエンジニアが生産性について思うこと - Sansan Tech Blog

                                              最近キーボードで文字を打つのが面倒になってきている技術本部 Eight Engineering Unitの斉藤です。 キーボードは既に100年以上使われ続けているみたいですね。そろそろ新しい入力の方法ができてもよさそうです。 例えば、頭で考えていることが文字に起こせたら、AIに任せるよりももっと便利だと思います。 前置きはさておき、Sansanではちょっと前にエンジニアの生産性と生産量の最大 化が話題になっていました。このブログをご覧の方ならご存知の方も多いのではないでしょうか。 私はこれまで何度か転職をしていますが、どの職場でも例外なくこの話題が挙がりました。 チームとして、あるいは事業としてどう最大化するかが基本前提となるのですが、私が今回話したいのは個人としての生産性の最大化についてです。 私は個人の生産性を上げることもチームの生産性を上げるのと同じくらい非常に大事なことだと考えてい

                                                30代からプログラミングを本格的に始めたエンジニアが生産性について思うこと - Sansan Tech Blog
                                              • 自分の心理的安全性を、自分で高める - Link and Motivation Developers' Blog

                                                エンジニアの梅原です。 少し前から「心理的安全性」というキーワードについて、疑問に思うところがあって色々と考えていて、 なんとなく考えがまとまったので、自戒も込めて文章として書き起こしてみました。 もともと社内向けに書いたものでしたが、思いのほか反響があったためこちらでも書いてみようと思います。 めちゃくちゃなこと言ってんな、って思う人もいるかもしれませんが、際に振ったときの思考実験だと思って読んでもらえると。 心理的安全性とは何か? 一般的に「心理的安全性」とは、以下の定義で語られます。 "A shared belief held by members of a team that the team is safe for interpersonal risk taking." (このチーム内では、対人関係上のリスクをとったとしても安心できるという共通の思い) Edmondson (19

                                                  自分の心理的安全性を、自分で高める - Link and Motivation Developers' Blog
                                                • X(元Twitter)を長年支えてきたエンジニアに、買収前後の中の様子はどうだったのか聞きました(CloseBox) | テクノエッジ TechnoEdge

                                                  イーロン・マスクによる買収以来、揺れ動いてきたTwitter(現在はXに改名)ですが、その内部がどのようになっていたのかはなかなか伺い知ることができません。筆者が個人的に参加しているポッドキャストbackspace.fmでは、TwitterのiOSアプリ開発に2010年から携わってきたソフトウェアエンジニアの丹羽善将(@niw)さんにその渦中の話を聞くことができました。 丹羽さんは、超有名テックブログのDaring Fireballで、世界で最も優れたiOS開発者の一人としてTwitter退社を惜しまれた人物です。 ▲Daring Fireballより 丹羽さんをゲストに迎えたエピソードは下のリンクからどうぞ。

                                                    X(元Twitter)を長年支えてきたエンジニアに、買収前後の中の様子はどうだったのか聞きました(CloseBox) | テクノエッジ TechnoEdge
                                                  • 無邪気なエンジニアリングができなくなってきた

                                                    タイトルの通り。好きでやっているエンジニアがだんだん好きではなくなってきたような気がして、改めて何が起きているのか、思考はまとまらないから箇条書きする。 無邪気なエンジニアリングとはコードを読む、書くのIOがとにかくたくさん気になったOSSやサービスはすぐさわる記事や登壇で書く以外のアウトプットもたくさん無邪気なエンジニアリングをして、これになりたかったインターネットで一発当てる著名なOSSのコミッターカンファレンスのプロポーザルをたくさん通す本をたくさん書いているたくさん質の良い記事を書いて凄い PV 数なりたかったのその行く末生活を全てエンジニアリングに捧げようとする無理あらゆる技術イベントに顔をだそうとする私生活や仕事でしばしば予定がつかずキャンセル帰りが遅くなるのが良くないので、家から近いイベント以外いかなくなった(規模の比較的おおきい)コミュニティを主催するスポンサー探しで苦労こ

                                                      無邪気なエンジニアリングができなくなってきた
                                                    • 「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog

                                                      YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために

                                                        「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
                                                      • 注意力散漫なADHDエンジニアへ「散漫さを武器にしよう」

                                                        重度のADHDでなくても、注意力が散漫、一つのことに集中できない、 興味の対象がすぐ目移りしてしまうタイプの人間は少なくないと思う。 特にIT系のエンジニアにはその傾向が多い気がする。 自分もその一人だ。 ふと隣のハイパフォーマーな同僚をみると、やるべき1つの仕事だけに数時間ずっと没頭して、ものすごい成果をあげている。 それを見て自分もタスクにとりかかるもやる気が起きず、つい趣味のコードを書いたり文献調査をして1時間を過ごしてしまう。 隣の彼の姿と自分を重ねると、自分はなんて生産性が低いんだと辟易としてしまう。 しかし、我々はそのフィールドで勝負をしてはいけない。 1つのことをずっとやり続ける集中力なんて持ち合わせていないし、多分一生手に入れることはない。 我々の武器は、様々なことに興味を持つことだ。 そして興味をもったことに対しては、「仕事として」ではなく「遊びとして」愛をもって取り組め

                                                          注意力散漫なADHDエンジニアへ「散漫さを武器にしよう」
                                                        • 電子工作で使われる圧着端子コネクタと圧着工具 - fumiLab

                                                          はじめに 電子工作で使われがちなコネクタを紹介し、使える工具を紹介します。これを見れば、これまでコネクタを使った電子工作をしたことがなくてもできるようなります。これを通して必要になった時に調べて自分で選んで使えるようになることを目指します。 色々コネクタ試して苦労した経験があったので参考にしてお金と時間と苦労を節約していただければ幸いです。 ※かなり前に記事を書きましたが、だいぶ古くなってきたのでここで書き直しておこうと思います。(前のは公開したままにしてありますが、こちらに誘導するようにしています) はじめに コネクタを使おう コネクタを使うメリット コネクタを使うとデメリット 電子工作で使われがちなコネクタ 信号用コネクタ 電子工作圧着端子早見表 QI2550コネクタ JST XHコネクタ JST PHコネクタ JST ZHコネクタ JST PAコネクタ JST NHコネクタ コネクタ

                                                            電子工作で使われる圧着端子コネクタと圧着工具 - fumiLab
                                                          • 実践要件定義入門 - 勘と経験と読経

                                                            最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その2。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ:本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に

                                                              実践要件定義入門 - 勘と経験と読経
                                                            • 登大遊、落合陽一を生んだ、未踏の父・竹内郁雄に聞く「優れたエンジニア」に必要なこと - エンジニアtype | 転職type

                                                              NEW! 2024.04.12 スキル 未踏落合陽一登大遊プログラマー 登大遊、落合陽一など数々のスーパークリエータを輩出してきた、独立行政法人情報処理推進機構(IPA)の「未踏IT人材発掘・育成事業」(以下、未踏IT)。その立ち上げから現在までを知るのが、統括プロジェクトマネージャーの竹内郁雄さんだ。 2017年には、ビジネスや社会課題解決につながる人材を発掘する「未踏アドバンスト事業」にも統括プロジェクトマネージャーとして参画。国際的なデファクトスタンダードとなるソフトウェアを日本から生み出すべく、人材育成に心血を注いでいる。 前身の未踏ソフトウェア創造事業から数えて24年。のべ2000人を超える修了生を見てきた竹内さんだから言える、優れたエンジニアに共通して求められる素養を聞いた。 未踏事業統括プロジェクトマネージャー(PM) 一般社団法人未踏 代表理事 竹内郁雄さん 1946年、富

                                                                登大遊、落合陽一を生んだ、未踏の父・竹内郁雄に聞く「優れたエンジニア」に必要なこと - エンジニアtype | 転職type
                                                              • エンジニアが今日から始める英語学習の継続方法 - Uzabase for Engineers

                                                                1. はじめに こんにちは。ソーシャル経済メディア「NewsPicks」でエンジニアをしております小林です! 皆さんは英語学習に取り組んでいらっしゃいますか?エンジニアとして技術ドキュメントや国際カンファレンスの動画等で英語に触れる機会があると思います。また、技術的なスキルはあるが、英語を話すことが苦手な場合、将来的に市場でどう評価されているかの動向も気になるところです。 最新の2023年度の報告によると、世界的にITエンジニアの給与が上昇している一方、日本では前年比USドルベースで5.9%減少、現地通貨(円)ベースでもわずか0.4%増加に留まっています。残念ながら、世界と比較した時に日本の給与の優位性がなかった一年となりました。今後もこの差が開く一方であれば、個人や企業が国際市場で競争力を保つために、英語能力の向上も必要になる機会が高まっていくことを示唆しています。 しかし、「英語力を伸

                                                                  エンジニアが今日から始める英語学習の継続方法 - Uzabase for Engineers
                                                                • プログラム初心者にC言語のポインタを不本意ながら教える羽目になったなら、こう教えると良いよ - 偏見プログラマの語り!

                                                                  僕がプログラミングに触れた当時は、プログラミングといえば「まず C 言語」でした。それから 10 年以上が経ちました。学校の授業や企業の研修では未だに C 言語を教えているところがあるようです。関数型プログラミング言語という波が来ている 2012 年にもなって未だに C 言語をやっているというのはまるで進歩が無く残念な気もしますが、比較的多くのプログラマに浸透している共通言語を最初に教えるというのは、一方では喜ばしい事だと解釈する事もできるのかもしれません*1。まぁとにかく、本意にせよ不本意にせよ現場で プログラム初心者に C 言語を教える羽目になった 人がたくさんいて、プログラム初心者なのに C 言語を学ばざるを得なくなった 若者がたくさんいるということです。 C 言語を教えるときに避けて通れないのがポインタで、プログラム初心者が C 言語を学ぶときにやたらとつまずく人が多いのがポインタ

                                                                    プログラム初心者にC言語のポインタを不本意ながら教える羽目になったなら、こう教えると良いよ - 偏見プログラマの語り!
                                                                  • ハッカーの呪いと共に生きる ~ The hacker is dead, long live the hacker! - An Epicurean

                                                                    私がWeb業界に入ったのは、ハッカーに対する憧れからです。その原体験を大事にしたいという気持ちを今でも強く持っています。 もう20年近く前になりますが、Web2.0の時代、私は傍観者でした。世界ではGoogleを筆頭として、日本でも、はてな社などが、エンジニアドリブンで個性的なサービスを生み出していました。他にもmiyagawaさんなど、個人で世界的に使われるようなOSSを開発している人もいました。書籍「ハッカーと画家」で描かれるような、ハッカーが個人技で大企業を出し抜く痛快さがありました。 そのように、WebサービスにせよOSSにせよ、同年代のハッカーが自分の技術でイノベーションを起こし、世の中に影響を及ぼしていることに羨望の眼差しを向けていたのです。 サブカル的な空気感も好ましく思っていました。西海岸のコンピュータ文化はヒッピーカルチャーの影響を受けていたのは間違いないでしょう。当時の

                                                                      ハッカーの呪いと共に生きる ~ The hacker is dead, long live the hacker! - An Epicurean
                                                                    • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

                                                                      公開日 2024/05/27更新日 2024/05/27注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女

                                                                        注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
                                                                      • なぜオフショア開発でベトナムがひとり勝ちしているのか?

                                                                        あなたは今、オフショアを検討しているが、様々な国の選択肢がある中で、なぜ「ベトナム」というワードをよく聞くのか気になっているところではないでしょうか。まず大前提として「ベトナム」を第一候補として取り上げるのは間違いないと言えるでしょう。 それではなぜ、ベトナムを第一候補として取り上げて良いのか?まさに、ベトナムにオフショア拠点としてラボを開設してから10年経ち、東建コーポレーション様やカインズ様といった誰でも耳にしたことあるような会社との取引を多数実績として持っている会社に所属している私がその背景とともに、ベトナムの魅力を紹介したいと思います。 そして、ベトナムに魅力を感じていただいたうえで、ベトナムの会社選びのポイントや開発を進めていく上で気を付けておきたいポイントを併せて紹介いたします。 1.なぜベトナム?オフショアでベトナムがひとり勝ちしている理由 オフショアといえばベトナムと言われ

                                                                        • mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論

                                                                          mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論 2024年6月18日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS(オープンソースソフトウェア)の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023年 GitHub Stars。著書に『みんなのGo言語』(2016年、2019年に改訂2版、技術評論社、共著)、『Go 言語プログラミングエッセンス』(2023年、技術評論社、単著)がある。関西在住。 X:@mattn_jp GitHub 前回はアウトプットとは何か、何のためアウトプットするのか、についてお話しました。筆者はこれまで、アウトプットのやり方で悩んでいる方々に、どう

                                                                            mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論
                                                                          • スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog

                                                                            今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し

                                                                              スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog
                                                                            • React

                                                                              2023年度リクルート エンジニアコース新人研修の講義資料です

                                                                                React
                                                                              • 自らを強いエンジニアにするための3つの習慣 / I need to be myself, I can't be no one else

                                                                                Developers CAREER Boost 2023 登壇資料

                                                                                  自らを強いエンジニアにするための3つの習慣 / I need to be myself, I can't be no one else
                                                                                • 「転職した方が上がる」エンジニア給与バブルの終焉と、雑すぎる一部人材紹介会社|久松剛/IT百物語の蒐集家

                                                                                  エンジニアバブルの終焉についてお話したものが2023年5月28日。あれから半年が経ち明確に転職時の給与についても影響が現れ始めました。スカウト媒体や人材紹介の状況を踏まえつつお話していきます。企業、候補者、そしてその間にある人材事業の事情と思惑を整理していきます。 有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。 伸び悩む給与提示2022年以前であれば積極採用企業が複数集まることで競りのような現象が起き、現年収に対し1.25倍以上の提示が見られました。これは「社内で出世するより転職した方が年収が上がる」という言説に繋がって行きました。 現在では現年収据え置き、もしくは+50万円程度が相場になっています。給与が大きく上がる場合は現職の待遇が相場より悪く、そのまま入社すると自社の給与水準より低くなる場合や、新卒より低くなるためといった背景が

                                                                                    「転職した方が上がる」エンジニア給与バブルの終焉と、雑すぎる一部人材紹介会社|久松剛/IT百物語の蒐集家