これまで未経験エンジニアに関する包囲網についてお話をしてきました。このお話は非常によく読んで頂いておりまして、本noteでも2番目のPVになっております。 未経験エンジニア、世間的には駆け出しエンジニアなどとも呼ばれていますが、こちらの状況が徐々に変わってきました。それが今回お話をする未経験フリーランスです。未経験フリーランスとはオンラインサロン・オンラインプログラミングスクールを出た後に直ちにフリーランスになるという状況です。今回はそのようなお話です。 有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。 ご覧頂きましてありがとうございます。 11月の公開以後、継続的にお読み頂いているものになります。 今は未経験エンジニアより未経験フリーランスの方へと情報商材市場が移ってきた感がありますね。こちらも書かねば。 https://t.co/M

こむろ＠事業開発部です。 前回 の続きです。 そろそろ諸々の記憶が薄れ始めている頃なので早めに全部書ききっておきたいところです。 前回までのまとめ データの取得と転送方法についての検討は終わりました。 Amazon S3 の転送方法の検討と想定される時間の計測 → 完了 Amazon ElastiCache for Redis の転送方法の検討と想定される時間の計測 → 完了 Amazon DynamoDB の転送方法の検討と想定される時間の計測 → 完了 転送対象の絞り込み → 完了 重要データ、ログイン情報の3テーブルにフォーカスを絞る 認証情報は除外 データ完全性検証の方法検討 → 未着手 全体のスケジュール作成 → 未完成 転送作業の実施 → 未着手 今回のテーマ データ完全性検証の方法を検討します。 データ完全性検証について。ここでは、「移行元のデータ」と「移行先のデータ」が完全

Spotify’s Failed #SquadGoalsを和訳してみました。 Spotifyは "Spotifyモデル "を使っていない。そして、あなたもそうすべきです。 スタートアップカルチャーの魅力の中でも、小規模なチームのスピードとアジリティに勝るものはありません。が、企業が成長していく中でこの感覚を維持することは困難です。2012年、Spotifyは新しい働き方を発表し、スピードとアジリティを理解したことを示唆しました。私が2017年にストックホルム本社のプロダクトマネジメント職の面接を受けたとき、Spotify Modelを実際に目の当たりにして興奮しました。しかし、最初の...

AWS Startup ブログ スタートアップのためのマイクロサービス入門 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 以前「スタートアップのためのコンテナ入門 – Kubernetes 編」を出した際に記事内で、マイクロサービスやサービスメッシュにふれる機会がありました。今回は AWS でデベロッパーアドボケイトをしているトリ氏 (@toricls) にマイクロサービスについて記事を寄稿いただきました。 ※ 本記事は Software Design 2020年7月号 に掲載された「スタートアップのためのAWSテクノロジー講座 – マイクロサービスのあるべき姿と特徴を知る」からの転載、改修版です。 目次 マイクロサービスにはコンテナが必要なのか？ サービスメッシュは本当に必要なのか？ 「マイクロサービス」という言葉の功罪 マイクロサービスが必

転職サービス「doda」などを提供するパーソルキャリア株式会社が運営するIT・テクノロジー人材のための社会人コミュニティ「TECH Street」＜ https://www.tech-street.jp/ ＞は、日本全国のITエンジニア403名を対象に「理想の開発環境に関するツール・サービス調査」を行いましたので、結果をお知らせいたします。 ▼調査結果詳細 https://www.tech-street.jp/entry/research-devenvironment ■ITエンジニアが使いたいのはどちら？Mac／Windows 「Q.ビジネスやプロジェクトにおいて、自分に決定権がある場合、どちらのPCを使いたいですか？」（n=403）と質問したところ、「Windows」と回答した方が90.1％、「Mac」と回答した方は9.9％という結果となりました。 また、「Q.PCを選ぶ上で最も重要視

こんにちは、@p1assです。 最近研修で Go を書いていて、その際にいくつか質問をされるのですが、聞いてみると前にも答えたような質問が多かったので、これを機にブログに参考リンクをまとめようと思います。 質問された際にすぐ答えられない質問も数多くあり、調べたり教えてもらったりすることで様々なことを再発見できました。 この記事では、質問に対する回答をできるだけ公式に近い文章を引用する形で書き記します。私個人の考えは別の段落になるようにして、事実と意見を区別するように心がけています。 なにか誤りを見つけた際は GitHub で PR を投げていただけると助かります。 言語仕様 関数の引数は値渡しか参照渡しか？ Go はすべて値渡し (pass by value) です。 ポインタの場合は、ポインタそのものがコピーされポインタの指し示す先の値はコピーされません。 Go の多値返却はタプルか？

Archie Gunasekara Staff Software Engineer, Cloud Foundations At Slack, we’ve gone through an evolution of our AWS infrastructure from the early days of running a few hand-built EC2 instances, all the way to provisioning thousands of EC2s instances across multiple AWS regions, using the latest AWS services to build reliable and scalable infrastructure. One of the pain points inherited from the earl

注意点 「霞が関を」としているものの、霞が関全体を語れる訳はないです。キャッチーにしたいがために目的語を大きくしました。あくまで一例。 現状に耐えきれなくなりそうで吐き出したかっただけです。お目汚しすいません。身バレは怖いので瑣末な部分にフェイクあり（というフェイクを入れておきます）。 私のスペック京大理系院卒基本情報、デスペ持ち、水色コーダー総合職、技官、4年目係長 今のポストは3ポスト目 なぜ去ろうと思ったか意思決定が科学的でない 誰々がこう言っているからこうなんだ 前回こうだったからこう これまでやってきたのだから今回もやらなければな 俺がそうだと思ったからそうなんだよなどなど、自分自身で考えることができていない人が多い。そもそも科学的な営みの経験がない人が圧倒的多数なので仕方のないことなのかもしれない。 勉強しない少なくとも総合職ならば、必死に勉強するものだと思っていたのだけど違う

Slack、1月の大規模障害の原因を説明。「AWS Transit Gateway」がトラフィックの急上昇に対応できず、AWSはアルゴリズムを見直すと AWSのネットワーク基盤の一部が飽和していた 1月4日、サービス内部のエラー率上昇によって始まったSlackの障害は、太平洋標準時の午前6時ごろからはSlackのWeb層の負荷が高まり、パケットロスを発生しはじめるなど徐々に深刻化。7時頃にはついにサービス停止にまで発展してしまいます。 負荷の解消のためにWeb層をスケールアウトさせるなどの対処を行い、なんとかサービスが復旧し始めたころに、AWSから障害の引き金となった現象についての報告が次のようになされたとのこと。 「Slack’s Outage on January 4th 2021」から引用します。 By the time Slack had recovered, engineers

AWS CDKでプロバイダーとしてTerraformが使える！！CDK for Terraformが発表されました！！ #awscdk AWS CDKがデプロイプロバイダーとしてTerraformをサポートしました！！！まだPreview版ですが、試しにVPCを作成してみました。 はじめに おはようございます、加藤です。私にとっては今年1番熱いアップデートが来ました！AWS CDKがなんとデプロイプロバイダーとしてTerraformをサポートしました！！！ ただし、今の所アルファテストステージなので、原則プロダクション環境に使うべきでありません、使う際は慎重に判断してから使用しましょう。 今まで、TerraStackIO/terrastackという同様にCDKでプロバイダーとしてTerraformを使おうとするプロジェクトはあったのですが、あまり開発は進んでいませんでした。なので、これまで

GitHub Actions 以前調べたのですが、いろいろあって個人プロジェクトでサクッとビルドするのみに使っていました。 今回改めて調べを進めたのでメモ。 幾つかのリポジトリを GitHub Actions に移行したけど、記事にしようとまとめてたらやった内容以上に調べることになってめちゃめちゃ時間かかった。 目次 目次 TL;DR トレンド GitHub Actions の基本 使用条件 使用制限 料金 ホストランナーの指定 ハードウェアリソース インストールされるツール IP OSの選択 実行権限 ファイルパス 環境変数 シークレット GITHUB_TOKEN コンテキスト Artifact トリガーイベント Cache Actions 通知 YAML Getting started YAMLシンタックス on env jobs.<job_id>.needs jobs.<job_id

Modern source-control systems provide powerful tools that make it easy to create branches in source code. But eventually these branches have to be merged back together, and many teams spend an inordinate amount of time coping with their tangled thicket of branches. There are several patterns that can allow teams to use branching effectively, concentrating around integrating the work of multiple de

住民にマイナンバー（個人番号）を知らせるための紙製のカードである「通知カード」が、5月下旬に廃止される予定だ。廃止によって（1）通知カードの新規発行・再発行、（2）通知カードの住所や氏名などの記載変更、の大きく2つができなくなるという。 ただし、当面の間は、通知カードに記載された氏名、生年月日、住所などに変更がない限り、引き続き通知カードをマイナンバーを証明する書類として使えるという。自治体では「この機会にマイナンバーカードを取得しましょう」と促している。なお、現在マイナンバーカードは、申請してから受取まで約1〜2カ月ほどかかるとのこと。 マイナンバーカードの受け取りは、本人確認のために役所に行く必要があるが、申請自体はオンライン（PC・スマホ対応）や郵便、街中の証明写真機からでもできる。今回はオンラインでの申請方法を紹介する。 PCから申請する場合は、申請用ウェブサイトにアクセスして、通

404。 エラーが発生しました。リクエストされた URL /blog/ja/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them はこのサーバーで見つかりませんでした。お知らせできる情報は以上です。

UI を大幅にアップデート！もっと使いやすくなった Slack仕事をより整理し、よりシンプルにするアップデートをリリース。 Slack チーム一同作成2020年3月18日 大企業から中小企業まであらゆる企業で働く何百万もの人にとって、Slack は毎日の仕事に欠かせない存在です。 Slack はコミュニケーションの方法を、サイロ化したメールからチャンネルベースのやりとりへと根本的にシフトさせました。有料ユーザーは平均で、1 日あたり 9 時間以上 Slack に接続しており、そのうち約 90 分間がアクティブな使用時間です。さらに、カスタマーサポートチケットの解決から最新の販売取引のモニタリングまで、Slack では毎週 50 億以上のアクションが実行されています。 私たちが実現したいのは、あらゆるチームのあらゆるメンバーが、プラットフォームのメリットを活用してコラボレーションできること。

以下のイベントの投影資料です。 https://event.shoeisha.jp/devsumi/20200213/session/2364/ 発表時の諸注意など http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P2 Agile Testing Fellow https://agiletestingfellow.com/ P15 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf P20 概説テスト分析 http://ww

Terraform Cloud は Terraform をチーム運用する際、安全に状態を共有しつつ変更管理を行えるアプリケーションです。 2019年9月10日行われたアップデートにより、機能が大幅に拡張されました。 同じチームで作業する場合は5人まで無償で使用でき、tfstateの管理、GitHub連携、planやapplyなどの基本コマンド実行などが可能です。 複数環境のTerraform運用 業務でTerraformを使う場合、production、staging、developmentなど複数の環境を管理する必要があります。 今回は Terraform Cloud を複数環境で運用するための設定をまとめて行きます。 構成は、共通の network 内で環境毎に subnetwork を作成し、 gce インスタンスを1つずつ配置する想定で進めます。 Terraformのディレクトリ構

*1 デフォルトでは Pod に割り当て可能なセカンダリ IP アドレスを ENI 1個分(その ENI に割り当てできる最大数)確保する設定ですが、実際には DaemonSet などがありすぐに ENI 1個分の空きという条件は満たさなくなるので、ワーカーノード起動時に ENI 2個分(「そのインスタンスタイプが ENI ごとに割り当てできる IP アドレス数」の2倍)が確保されるということになります。ドキュメントとしては次のリンクをご参照ください。 参考: https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cni-env-vars.html 参考: https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md 例えば、ピーク時に c5.4x