はじめに 本記事はアウトプットの心構えのカレンダー | Advent Calendar 2023の4日目の記事です こんにちは！！@Sicut_studyです！ 私はアウトプットの大切さを日頃から発信しており、実際にQiitaにたくさんの記事を投稿しています そんな中で、自分なりに高速に記事としてアウトプットできるフレームワークを使っているのでそのフレームワークについて紹介していきます アウトプットの大切さ まず言っておきたいのはアウトプットは質より量です 量が増えるとだんだんと質もあがります 私は駆け出しのエンジニアの方に普段から「100本記事を書けば人生変わる」と言っています。 そもそも世の中に100本記事を書いたことのある経験をしたことがある人はごく僅かです そんなごく僅かな人になれれば絶対人生が変わります。 多くの人ができないことをやり遂げられる。しかも記事という形で目に実力が見え
エンジニアの人に聞きたいんですけどインターネットって誰が運営してるんですか？プロバイダにはお金払ってますがそこには払わなくてもいいんでしょうか？
tomo @TomoEqual エンジニアの人に聞きたいんですけど、インターネットって誰が運営してるんですか？プロバイダにはお金払ってますがそこには払わなくてもいいんでしょうか 2023-10-26 07:47:07
「上司に質問をすると、いつも相手を不機嫌にさせてしまいます…」 このような悩みを持つエンジニアは少なくないのではないでしょうか。実際、誰もが「こんな質問をして怒られたらどうしよう」と躊躇したことがあるでしょう。 ただ、もしかしたらその悩みは簡単に解消できるかもしれません。なぜなら、エンジニアがイラっとする質問の態度はある程度きまっているからです。質問者として適切な態度を理解することで、質問が改善されるはずです。 はじめに まず、これは全員の共通認識だと思うのですが、大前提として『質問をすること』は難しいです。ですので、この記事ではあえて「良い質問」と「悪い質問」の違いには触れません。その手の議論にはすでに飽き飽きしているからです。 次に、エンジニアという生き物について説明します。多くのエンジニアは技術力を身につける必要があるため勤勉家な人が多いです。少なくとも私は「自分で学ぶ気のない人に厳
日本がIT後進国になったのは｢技術力の差｣ではない…数多のチャンスをすべて潰してきた｢著作権法｣という闇 アメリカが伸びたのは｢フェアユース｣があったから
厳しい著作権法が日本のITをダメにした 前回の記事（20年前なら日本のIT技術は世界一だった…天才プログラマーの7年半を奪った｢著作権法｣という闇）において、2004年にファイル共有交換ソフト「Winny」を開発した東京大学大学院特任教授（当時）の金子勇氏が著作権法違反幇助罪で逮捕、起訴されたことで、日本が世界のIT革命に乗り遅れた件を取り上げた。 その一方で、動画配信システム「YouTube」が生まれたアメリカでは、1998年に制定されたデジタル・ミレニアム著作権法で、検索エンジンや動画サービスなどのサービス・プロバイダーは、法律に定める要件を満たしていれば著作権侵害の責任を負う必要がなく、そのおかげでYouTubeが世界を席巻するようになったこともお伝えした。
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冊
技術記事を書くまでのステップについて順にコツを解説していきます。 特に、技術記事を書きたくてもテーマ選定が難しい、文章が苦手だ、なぜか筆が進まない、うまくまとめられないといった方に読んで欲しい記事です。 一応、エンジニア歴としては数年以内のジュニアレベルの方を想定しています。 以下のように技術記事を企画して、書いて、公開するためのプロセスごとにちょっとしたコツをまとめています。気になるセクションだけでも読んでいただければ幸いです。 テーマを決めよう 対象読者を決めよう 章立てを決めよう 書こう タイトルを決めよう 【余談】技術記事を書く理由とは 筆者について QiitaとZennにて6年以上の記事発信経験があり、 Qiitaでは5,942Contributionsを記録、 Zennでは3,253Likesをいただいています。 テーマを決めよう コツ：テーマのカテゴリによって執筆のポイントや
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
はじめに 本記事ではレベルアップしたいエンジニアが読んでおくべきQiita記事を紹介します。厳選に厳選を重ねた43記事です。全ての記事を読んでおく必要はありませんが、ちょっとでも「分からないな」「興味あるな」など思ったタイトルがあれば読んでみてください。 次の4種類に分類して紹介しています。参考にしてください。 フロントエンド バックエンド インフラ・Linux周りの知識 その他 それでは、早速紹介していきます！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 フロントエンド まず最初はフロントエンドエンジニアに読んでおくべきとおすすめできるQiita記事を11個選びました！フロントエンドエンジニアとしての基礎が身に付く
2023年に読んでよかった技術書
おそらく 2023 年に Zenn で出す最後の記事になるかと思います。 タイトルの通り、2023 年に読んだ本の中で、特に素晴らしかったものをご紹介します。 とはいえあまり今年は技術書を読んだ印象がなく… というのも、特定の xx(例えば Next.js、Ktor)といった部類に関しては公式のドキュメントを読むことがほとんどになり、書籍に求めるのは公式ドキュメントに書かれていない何かや誰かの経験・ノウハウになったからだと思います。 この記事を書くにあたって今年読んだ本を振り返ってみても、やはり十数冊程度(それでも月に 1 冊は読んでた)のでインプット：アウトプットの割合的には良いバランスではないかと思っています。 ただ、先に述べた通り公式ドキュメントに書かれていないなにかを売っている本というのはどれも本当の意味で価値があるものであり、皆さんにも本当に意味のある情報にお金を使っていただける
学生の頃インディーゲーム作ってて賞とか取ってましたていう新卒のエンジニアの子がいたんだけど会社でうまくいかなかった話→「ゲームに限らないな…」
BuchioGames @BuchioGames 本業はソシャゲのD/P/Mgr。個人的にもUnityでゲーム制作をやってます。 I'm a Japanese solo indie game developer. スマホ向け2.5D + 3Dアクションゲーム『SNO』体験版配信中 固ツイのリンクからDLできます！ lit.link/BuchioGames BuchioGames @BuchioGames 数年前、学生の頃インディーゲーム作ってて賞とか取ってましたていう新卒のエンジニアの子がいたんだけどこれが本当にうまくいかなかった 企画に納得いかない、ということが多々あったのだ 大規模開発になると企画、エンジニア、デザインと明確に分業し、それぞれの決定が重視される つづく 2024-05-25 11:22:04 BuchioGames @BuchioGames その子に関して僕が感じ取った
【緑色変】算数の教養がほとんどなかったプログラマがAtCoderを4年やって緑になれた話｜きりみんちゃんノート
こんばんみんみん。 バーチャル幼女プログラマーという肩書でインターネットをやっているきりみんちゃんというものです。 競技プログラミングのAtCoderというサービスに日々取り組んでいるんですが、この度めでたく緑レートになることが出来ました。 いわゆる色変エントリというやつです。 で、誰？3年前にこんなエントリを書いた者です。 VTuberをやったり絵を描いたりしてる社会人エンジニアです。 専門分野はAndroidでしたが、最近はフルスタックエンジニアを目指してフロントエンドやバックエンドなどをやっています。 現在のAtCoderコミュニティの中心層は理系の学生やもともと数学がかなり好きなタイプの人たちです。 一方きりみんちゃんはプログラマでありながら数学にコンプレックスがあり、それどころか小学2年までしか義務教育を受けていないため、中学、高校レベルの基礎的な数学の教養が全くありませんでした
〔Udemy初夏のビッグセール開催中〕エンジニア組織をまとめる技術─マネージャー歴12年のEMが語るプロジェクト・プロダクト・ピープルマネジメントに必要なスキル - はてなニュース
ソフトウェアエンジニアにとって、マネジメントの職に就くかどうかは大きな選択です。現在ではプレイヤーのままでスタッフエンジニアといった高い職位に進むキャリアもありますが、マネージャーとしてチームを率いてこそ達成できるビジネス上の成功もあるでしょう。 ひとくちにマネージャーといっても、マネジメントの対象によって要求されるスキルに幅があります。これまでUdemyの大きなセールで講座を紹介してきた当ニュースですが、今回はソフトウェア開発組織のマネジメントに必要となるスキルにフォーカスしました。 マネージャーという仕事と学びたいスキルを紹介してくれるのは、10年以上前からPM（プロジェクト・マネージャー）などに就いてチームを牽引し、現在はヘルステックベンチャーのカケハシでEM（エンジニアリング・マネージャー）を務める小田中育生（@dora_e_m）さんです。 また記事の後半では、マネジメントに関連し
「整理する時間のほうが無駄」→知り合いの日本を代表するというプログラマーから見る「雑然としたデスクトップは天才の証」説
らんぶる @tamuramble 知り合いの日本を代表するプログラマーのデスクトップもこんな感じ。 デスクトップ散らかってますねとイジったら、「ターミナルしか見てないし、ファイルもスポットライトで見つけられるので、整理する時間の方が無駄ですよ」って返されて以来、雑然としたデスクトップは天才の証だと思っています。 twitter.com/rikei_ayaka/st… 2023-08-07 09:40:32
【入門】基本設計
はじめに プロジェクトマネジメントの仕事をする際に、お客さんに提案ベースの要件定義や設計をする機会が増えてきたので、私の経験に基づいて基本設計の具体的なプロセスや考え方について、整理していきます。 以前投稿した記事の続きですが、未読でもこの記事を理解できるようになっています。 この記事の対象者 基本設計の思考プロセスを学びたい人 ビジネスサイドの要件をエンジニアサイドのシステムに落とし込む流れを学びたい人 ビジネスサイドとエンジニアサイドのコミュニケーション能力を向上させたい人 具体的な事例を通して基本設計を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要です 自分の経験に基づいた内容を言語化しています プロジェクト規模は10名から20名のシステム開発を想定しています(大規模なプロジェクトを想定していません) システム開発の全体像 今回は下記
テキストサイトのリンク集 SNSの停滞やAI学習の影響で、 個人サイトへの回帰が進む今日この頃。 ・・・ただ、良い個人サイトを見つけるのってなかなか難しいので、 定期的に最近みつけた個人サイトを紹介していくことにしました。 有名人、ただの一般人 関係なく、順序もごちゃ混ぜで紹介してます。 良い個人サイトが溜まってきたら、 いずれはジャンル分けしたリンク集も作ろうかと。 www.nejimakiblog.com 印象に残ったおすすめの個人サイト ( ) 内には、個人的なジャンル分けや特徴みたいなものを３語で書いてみました。 (※修正必要であれば、連絡頂けると変更します。誰も見てないと思うけれど） obake.blue (動画・デザイン・ユニーク) おしゃれすぎぃ！ UIもユニークで好き。 obake.blue 一番星の下で約束した日（テキストサイト・日記・音楽） Web拍手に定期的にコメント
WEB+DB PRESSと私
「大江戸Ruby会議10」での発表資料です。 https://regional.rubykaigi.org/oedo10/
インターホンをスマホに通知する方法をものすごく丁寧に説明する【Raspberry Pi Zero WH 】 - Qiita
在宅勤務している人、多いですよね。 いつでも配達を受け取れてとても助かります。 しかし...2階で仕事をしていると、 インターホンの音が聞こえにくい！ 他のことに集中していると気づかない！！！！ せっかく配達に来てくれたのだから、一発で受け取りたいものです。 エンジニアらしく仕組みで解決しましょう！ 忙しい人のための超要約 インターホンの室内モニタのA接点を使用します（鳴ると接点が閉じる） RaspberryPi Zero WH を用いて、A接点のオンオフによりGPIOの出力3.3VをGPIO17に印加する回路を組みます GPIO17に印加されたことをPythonスクリプトで検知します 検知したらLINE Messaging APIを使用してpush通知を送信します この説明で理解できる人は、記事全体を読む必要ないと思います。 電子工作初心者でも理解しやすいよう丁寧に書き上げたので、ぜひご
英語が話せてプログラムも書けるようになったのでより就職が難しくなった件について - Qiita
英語が話せてプログラムも書けるようになったのでより就職が難しくなった件について 最初の記事にも書きましたが、日本を離れて１０年以上、外資系の企業にて外国人と働き、または交渉事などをまとめ、何処に行ってもそれなりに不自由しない英語力を獲得し、さらにロックダウン中から２年あまり、毎日毎晩独学でコードを書き続けたことによって獲得したプログラミングスキルによりウェブアプリなどを自作できるようにまでなった訳ですが、そうして身につけた能力をフルに生かして条件の良い働き口を見つけてこましたろ と思った時に、そういった能力が身を助けるどころか、よりレッドオーシャンの荒波に我が身を晒すことになったことに気付き、愕然としてこの記事を執筆しています。 英語ができることによって競争が激化 例えば、自分は英語も話せて、プログラミングも出来ますよ となった場合、勿論グローバルな企業にて雇用されることを期待する訳ですが
秋のブログ週間2023の1日目です。 はじめに※この記事やこの本を読んだからと言って自身で診断を行わず、まずは整形外科などの医療機関にて診断を受けて、医師の方と治療方針を決定しましょう。また既に治療中の方は、取り組む前に一度医師や理学療法士の方と相談しましょう。 腰が痛くて仕事にならない、プログラマーこそが天職なのにこの痛みと一生付き合っていかないといけないのか…と思っている方は結構多いのではないでしょうか？ かく言う自分も腰痛持ちで、20代前半で椎間板ヘルニアと診断されました。当時はヘルニアが神経を圧迫し歩くのもつらい時期もありましたが、通院によってなんとか回復しました。 しかし完全にはよくならず、残りの人生全てを腰を気にしながら生きないといけないのか、、、と絶望しておりました。 そんなこんなで腰痛人生を送ってきたわけですが、ケリー・スターレット式 「座りすぎ」ケア完全マニュアルは自分の
『世界一流エンジニアの思考法』を読んでみて
はじめに みなさん、『世界一流エンジニアの思考法』読みましたか？（唐突） 結構 X（Twitter）で話題になっていたり、周りに読んでいる人も多かったので 年末年始のお休みに読もうと思ったら、あっという間に読了しました。 （電車の中で読んでいたら、同僚から「課題図書です」と連絡がきました。すごいタイミング） 知識の定着という意味でも、読んだことを書き出しておきたいと思います。 ※本の要約ではなく、私自身気になった点をピックアップしています。 偉大な習慣を身につけたプログラマになる 本書の「はじめに」にて 彼らはなにも全員が常人と比べて著しく頭の回転が速いわけでも、天才的記憶力を持つわけでもない。 主に「思考法」（マインドセット）が高い生産性を形づくっているのだ。 小手先のテクニックでもなければ Tips でもなく、その圧倒的なパフォーマンスは思考法から生まれているという事実。 いわゆる「一
100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
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
４年間、7色だけでUIをデザインし続けた話｜コウノ アスヤ
2019年にフリーランスとして独立した時すぐに声をかけていただいて、そこからずっとUIデザイナーとして関わってきた株式会社FLINTERSが今年で設立10周年なんだそうです。それを記念して、なんとメンバーでリレーしながら133日間ブログを書き続けるチャレンジに挑戦中とのこと。今回はその101日目の記事となります。 漫画アプリ「GANMA!」漫画アプリGANMA!僕が関わっているのはGANMA!のスマホアプリです。iOS向けとAndroid向けがあり、その両方のデザインを担当しています。 オリジナルの作品ですと、最近アニメ化された山田くんとLv999の恋をするなどが有名でしょうか。作品自体はいろんな漫画アプリで読めますが、原作はGANMA!発。最新話が最速で読めるのもGANMA!だけです。 GANMA!のデザイナーはずっと僕1人だけなので、僕の思想や判断がけっこう大きめにデザインに反映される
「デザイナーこそ、スプレッドシートに強くなれ」とずっと言い続けています。先日、とあるセミナー（#D2デザインダンジョン）で発したところ、「具体的にはどういうことでしょうか？」と質問いただきました。 よい機会なのでまとめてみました。重要なのは、スプレッドシートは数字はもちろんだけど、数字以外でも使いますよね、ということです。 なお、この記事では、次をまとめて「スプレッドシート」と記します。 Excel（デスクトップ版、オンライン版） Google スプレッドシート スプシ 表計算 Apple Numbers 「スプシ」という言葉には、なかなか慣れません… スプレッドシートは「思考の道具」である私自身、「マインドマップ」はよく使います。 マインドマップは思考を“発散”するには向いていますが、“収束”には不向き。たとえば、異なる“枝”のアイテムの関係性を表現できません。 詳しくは、こちらの記事に
はじめに こんにちは、WatanabeJin(@Sicut_study)です。 今回は私が初学者のときに最も苦労したDockerの技術を身につけるためのロードマップを紹介していきます。 Dockerが難しいのはなんといっても概念的なところだと思っています。新人時代の私は入社していきなり「Dockerで環境構築して」とだけ先輩に言われて何もわからない状態から自力でなんとか使えるところまで1ヶ月かけて学びました。(プログラミング経験なしでいきなりDockerは辛かった) その後、同じくプログラミング経験なしの方にDockerを指導した際に、この流れでやっていけば技術として身につくなと思ったのでまとめていきます。 概念が難しいDockerの学び方 私自身がものすごく1年目の時につまづいたDockerの勉強の仕方についてどのように身につけていったかを紹介します。… pic.twitter.com/
マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について - yo-log
Engineering Manager Advent Calendar 2023 7日目の記事です。 結論ファーストで書きます マネージャーは答えを持っていません。 大事なことなのでもう一度言います。 持っていません。 この問題ってそもそもなに？ 細かくみてみましょう。 マネージャーに全てを決められたくない マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。 ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck こちらのスライドにあるような「私考える人」的な動きになっているマネー
IT業界でストレスなく働くには - Qiita
はじめに ITエンジニアのみなさんこんにちは。 今日はIT業界でストレスなく働くということについて考えます。 GPT先生にお題を頂いてそれぞれコメントしていきます。 状況への適応の困難さ IT業界で最も多く発生しているのはこの要因かと思います。 ITエンジニアはSESなどで時間いくらで切り売りしている時給労働者ですが、簡単にはできない技術を提供することで高い単価を頂く仕事になっています。 学生さんから社会人になった人には分かりにくいですが、一定の期間内に一定の成果を出すといった点がコンビニのバイトとは大きく異なります。 現実の状況や要求が個人の能力や資源を超えている場合、適応することが難しくなります。このような状況では、ストレスが生じやすくなります。 誰にでも簡単にはできない技術 はマニュアル化されておらず、自分で状況を判断して適切な結果を出していく仕事となりますが、それができないとすると
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6
先日、個人開発していたzenncastというWebサービスをリリースしました。 Zennでトレンドになっている記事を、毎日AIが10分のラジオにして届けてくれるというサービスです。 ありがたいことに公開後はたくさんの方に試してもらえ、技術的な質問も多数いただきました。 このZennではzenncastの技術構成や仕組みを紹介します（プロンプトつき）。 作ったもの まずはエピソードを一つ選んで1分くらい聴いてみてください！ AIラジオの雰囲気が掴めると思います。 主な機能・特徴 毎朝10分のラジオを生成 Zennでトレンドになっている記事を要約して紹介 お便りを投稿すると、翌日のエピソードでAIパーソナリティが拾ってコメントしてくれる BGMをつけて爽やかな聴き心地 これらのステップは人の手を介さずすべて自動化されています。 Spotifyなどの各種プラットフォームへの配信はSpotify
はじめに この度、転職とスキル向上を目的に個人サービス(Football League)をリリースしました。 ITに関する学習は約1年ほど、その内の半年でサービスの開発をしました！ まだまだ修正箇所はあるものの、ひとまず形にはなったのでサービスの使用技術や開発過程を共有したいと思います。 私自身、独学で学習してきたのでそういった方々にとって少しでも参考になれば幸いです。 ご報告 現在権利関係について、本サイトで利用している外部APIの提供者様にお問い合わせしているため、メンテナンス状態とさせて頂いております。 ・メンテナンス時間 2024/01/18 15:45〜未定 自己紹介 商業高校卒(サッカー部⚽️) 25歳 青森住み🍏 職業はトマト農家です🍅 どのようなサービスか 本サービスは、欧州5大リーグのサッカーの試合結果やチーム情報などを閲覧することができるWebサイトです。 ただ情報
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか？ と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん（転職した人）の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか？ ・AWSなど
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
新人が1on1に来ない - Qiita
新人が1on1に来ない。その原因を考察する。 ここで出てくる新人の情報は以下である。 年齢: 30代前半 エンジニア歴: 5年 入社して半年 1on1を行うに至った経緯: 1年前、私と同じ時期に入社した同期Aが退職した。 詳細はよく分からないが、どうやらチームの先輩の1人と相性が悪いとの事だった。 尚、Aが退職したのは上記の理由だが、退職したいからこれを名目上の理由にしているのであって、原因は他にある可能性はあるが、この際それは考慮しない。 会社の人員構成: ほとんどがエンジニア歴10 ~ 20年のベテラン。平均年齢は30代後半。 Aは30代前半。 周囲の反応: Aが退職を告げた時、周囲はうろたえた。事前に相談は無かったし、特に問題はないように思われていた。 何より30過ぎた社会人は、問題があれば自分から話して来るという思い込みが、既存社員にあったもしれない。 年齢は関係あるか: ないと考
エンジニアが株式会社作ったログ
この記事を読んだ方から有益な情報をたくさんいただいたので追記している。 特定創業支援等事業の認定 法人設立ワンストップサービス gBizID 自分でやっていないものについては各項目で明記している。 なぜ作ったのか？ 自分の興味があった教育分野において、実際にやってみて自ら経験を積み、社会に役立つようなことがやりたいと思ったため。 あと、長くサラリーマンをやって、矛盾している組織が許せない性分だとわかったので、じゃあ自分で組織を作ってみようという単純な発想による。できるだけ矛盾していない組織を作ろうと目指しているが、やらずに文句だけ言うのはフェアでない、という意味合いもある。 フローチャート やることが多く、時系列がわかりづらかったのでフローチャートを書いてみた。 週一で動いた場合、 3 ヶ月ほどかかる。また、灰色の枠は実施していない。 経費について 登記前にかかった費用はすべて創立費、登記
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
IT 系に行くことはやめたほうがいいと思う
最近こんな感じの記事をいくつか見かけた https://xtech.nikkei.com/atcl/nxt/column/18/00001/08910/ IT 系の人が足りないとか言う話 また、子供になりたい職業のランキング上位に IT 系が上がったみたいな話もあった 個人的にはやめたほうがいいと思う IT 系エンジニアになりたいって思う人は基本自分が使ってるサービスとかに関わりたいと思ってるだろうけど そういうところ行けるのって IT 系でもごく一部 自分の好きなサービスの会社とまで絞り込むと採用される人数は限られてるし、人気があるから倍率も高い 難易度的には東大に入るよりも難しいんじゃない？と思うほど なので実際は IT 系を目指してもほとんどは底辺でブラックと言われる SIer とか SES などになる IT 系エンジニアって一応は専門職だし、必要な知識が多いし、なりたいと思ってすぐ
※かなり燃えてきたようなので、当初から内容修正してます。 先日、ビッグサイトで開催されている「Japan IT Week」に参加してきました。 この展示会、IT関連では一番大きな展示会、という事で、各メーカーさんともにかなり力を入れて参加している展示会だと思います。 ただ、その「力を入れている」が行き過ぎちゃって、かえって治安が悪くなっているなぁ〜なんて思ったので、今日はそのことについて書いてみたいと思います。 主催のRX Japanさん：過度な呼び込みをしている一部企業のせいで、展示会全体のイメージが下がってますよ。早めの対策を。 コンパニオンの皆さん：私も含め、皆様の絶え間ぬ努力を理解できない人間が多数いました。プロフェッショナルリズムを理解できなくてスイマセン。 参加者の皆さん：悪いのは過度な呼び込みをしている企業や個人です。現場の人に八つ当たりはしないでくださいね。 過度な呼び込み
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アウトプットガチ勢が作った高速記事作成フレームワーク - Qiita
プログラマーを苦しめてきた郵便番号データ「KEN_ALL.CSV」が改善！ 扱いやすい新形式／従来形式のデータも引き続き利用できるから安心してネ【やじうまの杜】
私がエンジニアをイラっとさせてきた質問時の態度5選 - Qiita
なかなかアウトプットできないあなたが技術記事を書くときのコツ
長く活躍できるエンジニアになるためには？ 技術者として大切にしたいこと
レベルアップしたい人必見 Qiita記事43選 - Qiita
おすすめの個人サイトや個人ブログを定期的にまとめることにした。 - 世界のねじを巻くブログ
腰痛と闘うプログラマー | フューチャー技術ブログ
「デザイナーこそ、スプレッドシートに強くなれ」の意味するところ｜鷹野 雅弘
【永久保存版】0からDockerを勉強するならこのロードマップに従え！ - Qiita
(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
AIラジオ『zenncast』の技術構成（プロンプトつき）
完全未経験が半年で個人サービスをリリースした話 - Qiita
30歳エンジニア転職で役に立たなかった経験と役に立った経験 - Qiita
キャリアハックの奇行 - Software Transactional Memo
タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
展示会で過剰な呼び込みをやめてもらえませんか？っていうお話。｜原田篤史_独立系水処理エンジニア