はじめに この記事は (Webアプリケーション開発プロジェクトでディレクター担当の) 私が経験した反省点を振り返り、みなさんと共有するものです。 プロジェクト管理における一つの重要なテーマ、バッファの設定について考えるきっかけにしていただければと思います。 まず バッファとは 「バッファ」とは何かを簡単におさらいしましょう。 プロジェクトのスケジュール見積もりにおいて、 不測の事態に備えて設けられる安全余裕のことです。 タイトルの回収 さて、私がなぜ1タスクごとにバッファを設けたのか？ 答えはシンプルに「その方がスケジュールの確度が向上する」と思ったからです。 (その方がエンジニアにも易しいのかな？とも思ったり…) しかし、 その後の学びを通じて、「タスクバッファ」よりも「プロジェクトバッファ」の方が効果的だと考えるようになりました。 （もちろん、100%正解かどうかは賛否ありそうですが）

案件でAWSの構成図を作成する機会があったので備忘兼ねて投稿します。 ※約5分で読めます 1. グループの内側から作成していく AWSの基本的なグループ構成はこんな感じ 添付の場合、個人的には Public subnet or Private subnet > Availability Aone > VPC > Region > AWS Cloudの順番で作成することをオススメします。理由は内側のグループが肥大すると外側のグループの手直しが発生するためです。 今回作成した時に外側から作成してしまい、めっちゃ時間がかかってしまいました... 2. グループの左上を掴む 日本語が下手ですみません。 なぜ左上を掴まないといけないか？試しにPublic subnetをクリックしてドラッグをすると、添付の様になりました。 クリックをするとグループの外から選択されてしまうため、選択したグループ内に存在

はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています

この記事はエンジニア転職 Advent Calendar 2023の11日目になります。 10日目はnewtaさんの「やりたいことをするための環境を探そう」でした。「野球をやっててもサッカーはうまくならない」というのには膝を叩いて納得してしまいました。確かにその通りですね。今後の参考にしたいと思います。 さて、この記事はアラフィフのおっさんエンジニアによる転職失敗談です。皆様の成功談のなかで恐縮ですが、他人の失敗から学べることもあると思いますので、よろしければご覧ください。 ざっくり自分の経歴 新卒でベンチャー企業に就職。約10年働くも倒産で解雇。 フリーランスのエンジニアになる。約10年働くも諸事情で廃業。 派遣でエンジニアとして働く。合間に転職活動も行って、何度か転職したこともあるけれど諸事情で数年で退職を繰り返すこと約10年。現在も転職活動中。 トータルで約30年のキャリアがあるわけ

プロジェクトでの進捗確認ミーティングもありますが、進捗を聞くだけに終始してしまいます。「働くこと」にもう少し視野を広げて、いろいろ聞いてみることがあります。1on1です。進捗確認MTGとは別の事柄を聞けます。以前は、1on1で質問される側でしたが、最近は1on1で質問をする側になったので、気づきをメモしておきます。 1on1の目的 1on1の目的は、（私の場合は）「心理的サポートをすること」です。別の言い方をすると、「働くことを通じて自己実現ができそうか/できているかを念頭に置き、会話を通して、精神面や志向についてプラスを大きく、マイナスを小さくするように働きかけること」です。 その上で、①働き方仕事内容の確認、②不安心配事の検知・助言、③成長・改善の意識付けという3つの観点から、プラス面、マイナス面を把握し、プラスを大きくマイナスを小さく働きかけます。 また、1on1をするときの基本的な

こんにちは。モロと申します。 実は数年前警察のお世話になり、数年裁判等をやって、昨年晴れて無罪放免となったのですが、そういえばその後どこにも情報をまとめていなかったことに気が付きました。 正直にいうとまったく気の進まない作業ですし、数年間これにかかりきりだったこともあり「わざわざまとめなくても誰でも知ってることでは……？」みたいな気持ちもあります。 とはいえ冷静に考えると大抵の人は一生関わり合いになることのない知識で、お世話になった界隈に対して何も残さないのも不義理という感じがしたため遅ればせながら筆を執らせていただきます。 はじめに 当記事は、実際に警察のお世話になり、数年間弁護士の方にご指導いただきはしたものの、あくまで法律の専門家でも何でもない一エンジニア（というか多少エンジニアリングをかじったデザイナー）によるもので、第三者による監修等もなされていません。 実体験に基づいて少しでも

はじめに みなさんの職場に古いインフラはありますか？ありますよね。 SVN,CVS...ですらないファイル名駆動のバージョン管理 id/pass不明でログインできない稼働中のビルドサーバ WindowsServer200X アンタッチャブルな巨大シェルスクリプト ... 小規模の会社でサーバサイドを齧っていると、 「クラウドネイティブ」という言葉とは無縁の世界で仕事をすることがあります。 え、そんなこと一度もない？ これからもあなたの幸運が続きますように。 改善活動スタート さすがに辛いので、改善を視野に入れて地道に調査をするわけです。 えいやで滅ぼしたい気持ちをグッと抑えます。 予算確保（のためのリスクの整理） 利害関係者の洗い出し 業務のフローで必須なインフラのリストアップ いざ置き換える算段がついたら、工事の計画を練ります。 業務の影響確認 バックアップ 移行期間の周知 等々。 現実

三行 報告と確認は大事だから怠らないように 手段と目的を履き違えるな 勉強は大事だから習慣化する(軽くでいい) 新人教育に手を出そうかと思ったんです おはようございます。この季節は手元が冷えまくってさむ谷園の冷え茶漬けなのでなるたけキーボードいじりたくないデブです。 私事ですが去年に転職しまして、いい感じにやれてます。フルリモート最高です。 そんなこんなでまあまあ月日も経って試用期間も終わり、前々から思ってた教育関連に手を出したいと本社で色々言ってます。 とは言え本社側としても長期で色々考えててとりあえず今々私が手を付けれそうなのが参画後研修というやつっぽい空気なのでそれ向けに一本記事を書きます。 で、その参画後研修の対象が以下の感じです。(以降新人君、とします) 研修終わって本格的に業務に参加しだした人 大体1,2年目くらい はい。大事な時期です。 どのくらい大事かと言うとアニメの1～3

といった感じです。（この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。） "No.～基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20～500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす

この記事はNuco Advent Calendar 2022の1日目の記事です はじめに やる気を削ぐ会議術 会議（かいぎ）は、関係者が集まり、特定の目的（議題）に関して意見交換・審議し、合意・施策などの意思決定をすること、およびその物理的構成員の集まりを意味する。 会議 - Wikipedia 仕事でエンジニアリングを行う人々にとって会議という営みは不可欠である。 そもそも会社という複数の人々の共同体を会議なしで運営することが不可能であることから、当然職業エンジニアにとっても会議は避けられない。 システムの仕様決めのためのチーム内外での話し合い 非IT部門に対するサポートのための説明会 顧客に対する技術的なプレゼンテーション 上司との1on1 etc... 上記のように様々な目的で会議は日々開催される。 開発が仕事であるエンジニアにとっては会議そのものは間接的な業務であるから、会議そのも

こんにちはISSUEを運営している寒河江です。 今回は情報の少ないWebエンジニアの業務委託単価相場について調べてみました。 現在の単価が適正単価なのか、次の単価レンジに行くにはどうすればいいか。ISSUEの実績をふんだんに使い記事を書いてみたのでご一読いただけると幸いです。 オリジナルの記事はこちら ISSUE DB 3,000人の実績データから相場を作成 現在(2022年11月)ではISSUE上に1,800人以上のユーザーデータと2,000以上の単価診断結果があります。またISSUEではクラウドソーシング形式で企業とマッチングすることにより、報酬を獲得することができます。その際の契約時給単価を参考に今回の相場作成の参考にしています。ISSUE上でもリアルタイムの単価相場を確認できますのでご参考ください。 Webエンジニアの業務委託単価相場 わかりやすいように各業務委託単価とその技術能力

精神を安定させることはコードの品質に繋がる 社内政治をせよ。 さすればレビュー指摘が柔らかくなる。 上司からの評価も上がるかもしれない。 実践した私は部下付きのマネージャーになった。（部下無しのマネージャーとはいったい…… ポイント１．指揮系統を認識せよ 誰の仕事をやっている？ その仕事はどのような権限で発動している？ 「部長からモック作成の依頼が先輩社員に降りてきて、先輩社員がその作業を自分に振ってきた」場合、 意識するのは次のこと。 １．何かトラブルがあった場合は部長へGO （先輩社員から言われた仕様が部長の意図と反している等 ２．何もしない場合、手柄は先輩社員が貰っていく （この作業、A君がやったんすよ～と先輩社員が部長に言うことは無いと考えて良い ３．本来の業務がある場合、優先順位をはっきりする。納期等に問題がある時は先輩社員に報告。状況によっては部長にも。 ４．終了報告はメール。

はじめに bash などのシェルには [ ... ] と [[ ... ]] の二種類の比較方法があります。一つはコマンド、もう一つはシェルの文法なのですが、具体的にはこの二つは一体何が違うのでしょうか？ そもそもなぜ似ている機能が二つもあるのでしょうか？ この記事は言語設計者の気持ちになって考えることで、その理由を解き明かそうという記事です。 なお、違いについての簡単な説明については「test と [ と [[ コマンドの違い - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 」の記事がよくまとめられていますので紹介します。一通りの違いを素早く知りたい方はこちらを参照してください。 参考 シェルの歴史や種類については「シェルの歴史 総まとめ（種類と系統図）と POSIX の役割」に詳しくまとめています（系統図とか頑張って書いたので見

先日Herokuの完全有償化が発表されて以降、蜘蛛の子を散らすようにHerokuからの脱出が図られています。 そんなわけで概ねHerokuの代替となりそうな無料サービスを紹介していきます。 ほとんどの代替サービスは完全無料というわけではなく、機能の少ない無料プランと高機能の有料プランが存在します。 有料化前のHerokuと同じということですね。 各サービスについて、実際に使ってみたという参考記事を貼っておくので、実際の使い勝手等はそちらを参照してください(他力本願） Qiita内に使ってみた記事が見つからなかったサービスは、日本では人気がないのだろうということで選外にしました。 また概要は、各サービスの説明やドキュメントに記載されているものです。 代替サービス一覧 FLy Flyはグローバルなアプリケーション配布プラットフォームです。 Turbokuを使えばHerokuアプリをFly.io

担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ

半分ネタ記事です。あんまり真面目に書きません。 項目数が多いので，気力でなんとか書きます。分類は諦めます。 他にもある！っていうのがあったらコメント欄で教えて下さい。気が向いたら追記します。 公式の TypeScript 型定義がもはや型定義を諦めている 辛い度: ★★★★★ 辛い中でもこれはかなり上位に来るやつ。 こちらに OpenAPI 形式で仕様が定義されていて， https://github.com/slackapi/node-slack-sdk/tree/main/packages/web-api/types ここに仕様に基づいて TypeScript の型定義ファイルが吐かれるようになっています。 Git 管理されていないので，実際のリリースを見てみましょう。 https://unpkg.com/@slack/web-api@6.7.2/dist/response/Reacti

{ "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // （ SQLite など他の RDS と競合させないためです。） // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq

三行でまとめると シグナルハンドラ内でprintf()してはいけない というより、余計な処理を書いてはいけない もう一度言う、シグナルハンドラで余計なことをするな、非常に大事なことだ はじめに シグナルハンドラでやってよい処理は非常に限られるのに、全くルールを守らないサンプルコードが世の中に大量に出回っている。printf()するなんてもってのほかなのだが、カジュアルにそこらじゅうで見かけて非常に悲しい。 この記事では、そんな状況を少しでも改善したいと思い初心者向きに書いたものだ。そのため、下記では、回避するにはどう実装すればよいのか、ルールを破るとどうなるのか、といった点を先に簡潔に記述する。 なぜしてはいけないのか、POSIXだとかリエントラントだとか、は下の方に追いやっている。玄人は読んでてウズウズするだろうが、細かい話はできるだけ目につかないような構成としたため了解いただきたい。

なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル

実行中のシェルスクリプトを編集すると実行している途中から動作を変えることができることはよく知られている。 例: http://d.hatena.ne.jp/sleepy_yoshi/20090917/p1 「変えることができる」というよりも現実のケースでは、実行中に意図せず内容を変えてしまうことで予想しない挙動をさせてしまうことがありうる。これを防ぐにはどうするか。 例 次のようなスクリプトを実行中に書き換えてみる