インターホンをスマホに通知する方法をものすごく丁寧に説明する【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 でもなく、その圧倒的なパフォーマンスは思考法から生まれているという事実。 いわゆる「一
４年間、7色だけでUIをデザインし続けた話｜コウノ アスヤ
2019年にフリーランスとして独立した時すぐに声をかけていただいて、そこからずっとUIデザイナーとして関わってきた株式会社FLINTERSが今年で設立10周年なんだそうです。それを記念して、なんとメンバーでリレーしながら133日間ブログを書き続けるチャレンジに挑戦中とのこと。今回はその101日目の記事となります。 漫画アプリ「GANMA!」漫画アプリGANMA!僕が関わっているのはGANMA!のスマホアプリです。iOS向けとAndroid向けがあり、その両方のデザインを担当しています。 オリジナルの作品ですと、最近アニメ化された山田くんとLv999の恋をするなどが有名でしょうか。作品自体はいろんな漫画アプリで読めますが、原作はGANMA!発。最新話が最速で読めるのもGANMA!だけです。 GANMA!のデザイナーはずっと僕1人だけなので、僕の思想や判断がけっこう大きめにデザインに反映される
「デザイナーこそ、スプレッドシートに強くなれ」とずっと言い続けています。先日、とあるセミナー（#D2デザインダンジョン）で発したところ、「具体的にはどういうことでしょうか？」と質問いただきました。 よい機会なのでまとめてみました。重要なのは、スプレッドシートは数字はもちろんだけど、数字以外でも使いますよね、ということです。 なお、この記事では、次をまとめて「スプレッドシート」と記します。 Excel（デスクトップ版、オンライン版） Google スプレッドシート スプシ 表計算 Apple Numbers 「スプシ」という言葉には、なかなか慣れません… スプレッドシートは「思考の道具」である私自身、「マインドマップ」はよく使います。 マインドマップは思考を“発散”するには向いていますが、“収束”には不向き。たとえば、異なる“枝”のアイテムの関係性を表現できません。 詳しくは、こちらの記事に
IT系を腐す文化本当にやめてほしい
学生のころ、IT土方がどうとかで業界がだいぶまずい場所だと文系の大学生の自分は思い、とても興味のある分野だったけどやめた。 それから5年がたち、今の職業を続けていてもと感じて、ずっと抱えていた興味に素直になろうと思い半年独学し、SES系の会社に転職した。 DBすらよくわかっていない状態だったけど、めちゃくちゃ楽しくて毎日充実しているし、3年たったけどまだ楽しい。 会社で学んだことを活かして個人開発したらまたそれで収入が増えてスキルが上がり、それを会社で活かせば褒めてもらえてより難しい課題に挑め、また更にスキルアップしてより難しい個人開発に挑める。 だからこそ新卒の時入社で来て居たらなぁと思うし、最近では自分と同じようにもっと早く業界に入っていればという中途の人にも出会った。 「他人の言葉に流されるなんてその程度」 そういう意見もあるかもしれないけど、ネット上での世論が世の中に影響を与えるよ
はじめに こんにちは、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
はじめに この度、転職とスキル向上を目的に個人サービス(Football League)をリリースしました。 ITに関する学習は約1年ほど、その内の半年でサービスの開発をしました！ まだまだ修正箇所はあるものの、ひとまず形にはなったのでサービスの使用技術や開発過程を共有したいと思います。 私自身、独学で学習してきたのでそういった方々にとって少しでも参考になれば幸いです。 ご報告 現在権利関係について、本サイトで利用している外部APIの提供者様にお問い合わせしているため、メンテナンス状態とさせて頂いております。 ・メンテナンス時間 2024/01/18 15:45〜未定 自己紹介 商業高校卒(サッカー部⚽️) 25歳 青森住み🍏 職業はトマト農家です🍅 どのようなサービスか 本サービスは、欧州5大リーグのサッカーの試合結果やチーム情報などを閲覧することができるWebサイトです。 ただ情報
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか？ と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん（転職した人）の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか？ ・AWSなど
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 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 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
今年の頭にうちの会社にやってきたエンジニアの話。 彼は実装がめちゃくちゃ速く、コードもきれい。テストもちゃんと書く。 とてもできるエンジニアなのだが、一つだけ困っていることがある。 実装完了した機能をすぐに本番環境にデプロイできないと、とても不機嫌になるのだ。 うちの会社が開発しているのはtoBのシステムで、実装内容によっては営業やカスタマーサポートからお客さんにアナウンスがされてからでないとデプロイができないものがある。 急にUIが変わったり新機能が追加されるとお客さんが混乱するしカスタマーサポートに問い合わせが殺到するので、デプロイ前に調整が発生するのは致し方ないことなのだが、こうした背景を説明しても彼は納得してくれない。 「とにかく早くデプロイをさせろ」の一点張りで、彼が勝手にPRをリリースブランチにマージして、機能が出てしまったこともある。 それによってカスタマーサポートへの問い合
新人が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さん：過度な呼び込みをしている一部企業のせいで、展示会全体のイメージが下がってますよ。早めの対策を。 コンパニオンの皆さん：私も含め、皆様の絶え間ぬ努力を理解できない人間が多数いました。プロフェッショナルリズムを理解できなくてスイマセン。 参加者の皆さん：悪いのは過度な呼び込みをしている企業や個人です。現場の人に八つ当たりはしないでくださいね。 過度な呼び込み
30代からプログラミングを本格的に始めたエンジニアが生産性について思うこと - Sansan Tech Blog
最近キーボードで文字を打つのが面倒になってきている技術本部 Eight Engineering Unitの斉藤です。 キーボードは既に100年以上使われ続けているみたいですね。そろそろ新しい入力の方法ができてもよさそうです。 例えば、頭で考えていることが文字に起こせたら、AIに任せるよりももっと便利だと思います。 前置きはさておき、Sansanではちょっと前にエンジニアの生産性と生産量の最大 化が話題になっていました。このブログをご覧の方ならご存知の方も多いのではないでしょうか。 私はこれまで何度か転職をしていますが、どの職場でも例外なくこの話題が挙がりました。 チームとして、あるいは事業としてどう最大化するかが基本前提となるのですが、私が今回話したいのは個人としての生産性の最大化についてです。 私は個人の生産性を上げることもチームの生産性を上げるのと同じくらい非常に大事なことだと考えてい
自分の心理的安全性を、自分で高める - 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
この記事を公開するかどうかかなり迷った。こんなことを全世界に公開しても自分の価値を下げて損するだけだけだし、世渡りが上手い人は不調な時に不調ですなんて公言しない。不調は隠してどうにかして、あとから「あの頃は実は辛かった」と言った方がずっと賢い。 でももう何をどうすればいいのかさっぱり分からないしとにかく吐き出したいんだ。 人生がかなり厳しい状況になっている。 いや、人によってはそのくらいなんだと思う程度かもしれないが、自分にとってはどうすればいいのか分からない状態なので、とりあえず聞いてほしい。 自己紹介 32歳フリーランスAndroidエンジニア 引きずるコロナ禍の影響 コロナ禍でリモートワークになってから仕事も生活も上手くいっていないという話は何度かこのブログにも書いてきました。 具体的にはリモートワークだとどうしても気が引き締まらないことやコミュニケーションの難しさなどからパフォーマ
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず
D-Plus Tokyo #1 https://d-plus.connpass.com/event/315744/
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
X（元Twitter）を長年支えてきたエンジニアに、買収前後の中の様子はどうだったのか聞きました（CloseBox） | テクノエッジ TechnoEdge
イーロン・マスクによる買収以来、揺れ動いてきたTwitter（現在はXに改名）ですが、その内部がどのようになっていたのかはなかなか伺い知ることができません。筆者が個人的に参加しているポッドキャストbackspace.fmでは、TwitterのiOSアプリ開発に2010年から携わってきたソフトウェアエンジニアの丹羽善将（@niw）さんにその渦中の話を聞くことができました。 丹羽さんは、超有名テックブログのDaring Fireballで、世界で最も優れたiOS開発者の一人としてTwitter退社を惜しまれた人物です。 ▲Daring Fireballより 丹羽さんをゲストに迎えたエピソードは下のリンクからどうぞ。
アプリ開発市場の現状と今後の予想（2023〜2026） - IT業界で気づいたことをこっそり書くブログ
最近、ブログで長文を書く体力が落ちてきているので、かんたんに書こうと思います。 Flutterが流行ってるようです Flutterエンジニアが足りてないようです iOSエンジニア、AndroidエンジニアはなぜFlutterをやらないのか？ Flutterはどのくらい工数を圧縮できるのか？ Flutter案件は今後更に増えるか？ iOS/Flutterエンジニア、めちゃくちゃ少ない説 Android / Flutter / iOSで分断が起こるのでは？ SwiftUI+combineは増えてる？ iOSエンジニアが問われる、SwiftUI or Flutter 結果、人材不足が予想される 新人に期待はできるか？ まとめ 補足 Flutterが流行ってるようです 流行りそうとか、そういう「かもしれない」ではなく。 ベンチャーの新規アプリ案件のFlutter率が明らかに高く以前より上がっている
引く手数多そうなエンジニアがムカつく
他に行く当てなんていくらでもありますよとでも言わんばかりの態度がムカつく。 はいはい正論ですよ、転職副業あたりまえ終身雇用絵空事。 でもさ、会社に来てるんなら会社に参加しなよ。 何のアイデアも「難しいですね」「技術的には可能ですが」「そもそも要ります？」 なんかさ、気概が感じられんのよ。 内心なんてわかりっこないけどさ。 会社の事業とか理念とか関係ない、どうせ転職するまでのつなぎ、私は何も困りません、みたいにさ、見えちゃうのよ。 泥臭くてもやらなきゃいけないときもあるじゃん。 実現したいときもあるじゃん。 何でそんな事なかれ主義なんだろう。 そんなに優秀で、ありとあらゆる技術を手足のように使いこなして、なんで志がないんだろう。 お金とか見返りとかキャリアとかポートフォリオとか。 自分、自分、自分、メリット、メリット、メリット。 ちょっともう、うんざりしちゃうよ。 ハッキリ言って。 これはN
はじめに エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。 私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。 (かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。 「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。 成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。 （世阿弥の「風姿花伝」でも「真似る」
はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理
重度のADHDでなくても、注意力が散漫、一つのことに集中できない、 興味の対象がすぐ目移りしてしまうタイプの人間は少なくないと思う。 特にIT系のエンジニアにはその傾向が多い気がする。 自分もその一人だ。 ふと隣のハイパフォーマーな同僚をみると、やるべき1つの仕事だけに数時間ずっと没頭して、ものすごい成果をあげている。 それを見て自分もタスクにとりかかるもやる気が起きず、つい趣味のコードを書いたり文献調査をして1時間を過ごしてしまう。 隣の彼の姿と自分を重ねると、自分はなんて生産性が低いんだと辟易としてしまう。 しかし、我々はそのフィールドで勝負をしてはいけない。 1つのことをずっとやり続ける集中力なんて持ち合わせていないし、多分一生手に入れることはない。 我々の武器は、様々なことに興味を持つことだ。 そして興味をもったことに対しては、「仕事として」ではなく「遊びとして」愛をもって取り組め
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
腰痛と闘うプログラマー | フューチャー技術ブログ
「デザイナーこそ、スプレッドシートに強くなれ」の意味するところ｜鷹野 雅弘
【永久保存版】0からDockerを勉強するならこのロードマップに従え！ - Qiita
(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
完全未経験が半年で個人サービスをリリースした話 - Qiita
30歳エンジニア転職で役に立たなかった経験と役に立った経験 - Qiita
キャリアハックの奇行 - Software Transactional Memo
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
プログラミングにしか興味のないエンジニアに困っている
展示会で過剰な呼び込みをやめてもらえませんか？っていうお話。｜原田篤史_独立系水処理エンジニア
追い詰められている - みんからきりまで
メンテのいらないソフトウェア - 誰かの役に立てばいいブログ
ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
若手のうちに知りたかった生産性の高め方
「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
つよつよエンジニアの成果物にある5つの特徴 - Qiita
どうしてあなたの共通化は間違っているのか：目次 - Qiita
注意力散漫なADHDエンジニアへ「散漫さを武器にしよう」
実践要件定義入門 - 勘と経験と読経
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog