なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか？ - Qiita
はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム
Snowflake で1万"列"データを扱う技術 - Qiita
そうです。わずか10行しかないデータですが、 15,000列 あります。 「それデータモデリングをミスってるやん」というツッコミはあると思いますが、今回はそのあたりについてはノーコメントです。諸事情ありこのようなデータを扱うことになりました。 今回は Snowflake でもなかなか扱うことが難しい (横方向に) クソデカデータの世界 をご案内したいと思います。 クソデカテーブルを作る まずテーブルを作ります。 この時点でエラーが出てくれるならまだ良かった。。。 なんとこのクエリは問題なく実行でき、テーブルは作成できます。 作成できてしまいます。 作成できてしまったが故に、「さすが Snowflake、列数が多いテーブルも簡単に扱えるんだね!!」と高をくくってしまいます。 ちなみに PostgreSQL の場合は1テーブルあたり最大 1,600 列だそうです。まぁそれだけあれば普通は困らな
2年前の自分に教えたい！HTB（ペネトレーションテスト）で生き抜くためのツールやサイトまとめ - Qiita
HTBをこれから始めようとしている皆さん！ようこそペネトレの世界へ！ 今回の記事は私が2年前、ちょうどHTBを始めたばかりの頃に知っていたかったツールやサイトをまとめました！何も知らない状態から血を吐きながら集めた精鋭たちなので、ぜひ参考にしていただけると嬉しいです！ HackTheBoxってなに？という方はこちらの記事を見てみてください！ 正直、おすすめを挙げ出すとキリがないので、今回は特にお勧めできるツールやサイトを紹介しています。 中級者や上級者の方はすでに知っている情報が多いと思います。もし、他にも便利なツールがあれば教えていただけると嬉しいです！ ペネトレと言えばOSCP！ということで記事の最後にはOSCP合格のためのプチ情報もまとめていますので、最後まで閲覧ください〜！ それでは記事の本編に入りましょう！ ツールまとめ まずは、HTB（ペネトレ）を行う上で最強のツールたちを紹介
フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
【Linuxカーネルを読む】ChatGPTで爆速コードリーディング - Qiita
はじめに OpenAIによって開発されたChatGPTが話題になっています。特に、2023年3月14日に公開された最新モデルであるGPT-4は、これまで私達がAIに持っていた認識を根底から覆したのではないでしょうか？ 私は、「普通に人間とやりとりしているのと変わらんやん…」と率直に驚きました。 エンジニアの業務の中でも、自動コーディング支援、技術的課題の壁打ち相手、ドキュメント自動生成、学習支援等さまざまな用途に活用する可能性を皆さん検証している段階です。私もその波に乗っている真っ最中です。 そこで今回は、ソースコードリーディングをChatGPTをメンターにしたら爆速にできるのではないか？という仮説を検証してみました。 そしてどうせやるなら、ソースコードリーディングのハードルの高さナンバーワン（個人調べ）の「Linuxカーネル」を題材にしてみました。 なお、使用したモデルはGPT-4です。
Accuracy/Recall/Precisionってややこしくない?? - Qiita
という感じの表(混同行列というらしい)が出てきて、いろいろ説明されていますが 陽性/陰性とかPositive/Negativeとか言われても、いまいちピント来きません！！！ ということでいろいろ調べていたら、以下のブログにとてもわかりやすく説明されていた。 https://towardsdatascience.com/data-science-performance-metrics-for-everyone-4d68f4859eef 備忘もかねて、この記事にまとめます！ ケース ある医者が透析している患者が来週中に入院するか/しないかを予測する 医者の予測結果をベン図にすると以下のようになります。 入院すると予測 True Positives(TP) : 本当に入院した => 予測は正解 False Positives(FP) : 入院はしなかった => 予測は不正解 入
RSAの終わりの始まり - 暗号移行再び - Qiita
前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗
開発生産性について議論する前に知っておきたいこと - Qiita
はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が本当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「
なぜETLではなくELTが流行ってきたのか - Qiita
概要 troccoの生みの親で、現プロダクト責任者をしている @hiro_koba_jp です。 troccoアドベントカレンダー2022の1記事目書いていきます！（みんなも参加してね） データ分析やデータエンジニアリングにおいてETL(Extract Transform Load)という言葉を耳にしたことがある方は多いのではないでしょうか？ 一方、「ETLではなくELT（音楽グループではない）が主流になりつつある」といったような論調も増えてきました。 この記事では、ETLとELTの違いや、なぜELTにシフトしつつあるのか、この先どうなるのか（予想）について、私なりの見解を書いてみようと思います。 一昔前まではETLパターンが多かった Redshiftが登場した2013年頃、人々はデータレイク層はS3上で構築し、データウェアハウス層〜データマート層はRedshift上に組む人が多かったよう
セキュリティーチェックシートという闇への防衛術 - Qiita
といった感じです。（この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。） "No.～基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20～500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす
GoogleのShell Style Guideの邦訳 - Qiita
背景 (Background) どのシェルを使うか (Which Shell to Use) Bash は実行が許可された唯一のシェルスクリプト言語である。 実行可能ファイルは #!/bin/bash と最小限のフラグで始めなければならない。シェルオプションの設定に set を利用することで、 スクリプトを bash script_name として呼び出してもその機能を損なわないようにせよ。 全ての実行可能シェルスクリプトを bash に制限することで、全てのマシンにインストールされた一貫したシェル言語を得る。 これに対する唯一の例外は、コーディング対象によって強制される場合である。この1つの例として、Solaris SVR4 パッケージは、どんなスクリプトにも plain Bourne shell であることを要求する。 いつシェルを使うか (When to use Shell) シェル
そろそろオープンデータを無秩序に管理するのは卒業したいので📦データを管理するパッケージマネージャを開発した【ツール開発】 - Qiita
今回はdim(オープンデータパッケージマネージャ) v1.0のリリースに伴って開発したツールの紹介をしたいと思います。 オープンデータもパッケージマネージャ(apt、npm、gem、pipなど)と同じようにnpm install xxxxxのような形でオープンデータをインストールして管理すると良いのではないかという話です。 以前のバージョンに関しては以下の記事で紹介 【個人開発】パッケージマネージャーの考えを流用してオープンデータ管理ツールを作ってみた話 以前の記事を読んでいてv1.0からの変更点に関して読みたい方 dim v1.0 変更点 オープンデータを無秩序に管理するのはやめたい ソフトウェアやライブラリの管理は世の中様々な体系化された方法が確立されつつあります。ソフトウェアであればaptやbrewなど、ライブラリであれば言語ごとにnpmやgemなどが存在します。しかし、データに関し
サブスクリプション型のビジネスなら見ておくべき5つの超重要チャート - Qiita
サブスクリプション型のビジネス、またはソフトウェアの世界ではSaaSと言われたりする、顧客が製品やサービスを継続的に利用するために購読するタイプのビジネスは一般的な売り切り型のビジネスとは収益構造が異なるため、ビジネスを成長させるために見るべき指標やチャートも違ってきます。 よくあるのは、この違いを意識せずに「売り切り型」のビジネスでよく使われる指標やチャートをモニターしていたがために、ビジネスの成長のきっかけをつかめなかったり、成長していると思っていたビジネスが急に傾き始めたり、成長の見通しを社内で共有、または外部の投資家にうまく説明できなかったり、という問題です。 そこで、こちらの記事ではサブスクリプション型のビジネスを成長させるために欠かせない5つのチャートを使った簡単な分析手法を紹介させていただきます。 1. コホート分析（生存分析） コホート分析（生存分析） は顧客のチャーンやリ
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
九州大学のアプリを一カ月で作ってみたら、Appstoreで94位になっちゃった。 - Qiita
はじめに 皆さんは、少し前に話題になった九州大学アプリをご存知でしょうか？ 本アプリはTwitterなどのSNSで拡散されるなどして、AppStoreにて94位を記録いたしました。1 また、現在のインストール数は、九大生人口の20%を超えております。2 さらに、星5評価が150件を超えるなどもしました。 今回は、制作時に得た知見を共有することで、皆さんのお力になれたらと思います。 また、皆さんからいろんなアドバイスをいただきたいとも思っているので、ぜひよろしくお願いします。 自己紹介 九州大学、学生のKaede Gamesです。 チームではなく個人開発です🍁 アプリの概要 主な機能は3つ クラウド過去問 デジタル学生証 ニュース を実装しています。 また、PVとして以下の動画（18秒ほど）を制作しているので、見て頂けるとわかり良いかと思います。 制作背景 コロナ禍で繋がりにくさを感じる学
AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴 - Qiita
著者: 伊藤 雅博, 株式会社日立製作所 はじめに AWSでストリーム処理を実現する際は、データをキューイングするメッセージングサービスと、キューイングしたデータをストリーム処理するサービスを組み合わせることが一般的です。本投稿では、AWSが提供する各メッセージングサービスのうち、ストリームデータを扱う際によく活用されている下記サービスの特徴を紹介します。 Amazon Kinesis Data Streams (KDS) Amazon Managed Streaming for Apache Kafka (MSK) Amazon Simple Queue Service (SQS) なお、本投稿の内容は2020年中頃の調査結果をベースに、いくつか更新を加えたものです。AWSのサービス仕様は随時更新されるため、最新の仕様とは異なる場合があります。最新の情報はAWSの公式ドキュメントをご参照
自然言語処理ライブラリspaCy/GiNZAのオンラインデモサイトを立ててみた - Qiita
はじめに Mecabには形態素解析ウェブアプリUniDic-MeCabやMeCab/Unidic Demonstration といったオンラインデモサイトがありますが、2022年3月現在spaCy/GiNZAのデモサイトはなさそうなのでHerokuで立てました。 2022年11月Herokuの無料枠が終了したため、Render.comで立てました。 実際に動かしてみるとこんな感じです。 さっそく、オンラインで試したいという方は下記にアクセスしてみてください。 https://chai3.github.io/spacy-ginza-online-demonstration/ spaCy/GiNZAとは GiNZA は、Universal Dependencies(UD)に基づいたオープンソースな日本語処理ライブラリです。 spaCyというMITライセンスで商用レベルな自然言語処理フレームワー
本のバーコードを読み取ってNotionで読書録を作成するアプリを作ってみた - Qiita
はじめに はじめまして。インディーゲームを作っております、nyorokoと申します。 ゲームづくりの他に読書が好きで、「読書録を簡単に作成・管理することはできないか？」という問題意識があり、タイトルの通りのアプリを作ってみました。 2022/5/23 思ったよりも反響があったため、加筆した第二弾を公開しました！ 完成したもの 以前Notion APIを用いて、 本のバーコードを読み取る →ISBNを取得する →ISBNから本の情報を取得する →Notionのデータベースに追加する という一連の動作を行うアプリを開発しました💪🏾(´･_･`💪🏾) pic.twitter.com/GqPBPV7sin — nyoroko (@nyoroko_nyoro) February 21, 2022 Notionとは？ Notion公式サイト Notionとは、タスク管理やメモ等を一元的に行うこ
Webフロントエンドパフォーマンスチューニング80選 - Qiita
こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇％アップ、CVR〇％アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを片っ端から試していくボトムアップなアプローチも有効になることもあったり、日々のコーディングでパフォーマンスを意識したコードを書くことは大切でしょう。 この記事ではパフォーマンス最適化のハウツーを紹介します。 パフォーマンス改善の施策が思い浮かばない時やフロン
PythonでAPIを爆速で構築してみた - Qiita
目次 1.はじめに 2.コーディング 3.コンテナ化 1. はじめに 友人に「PythonでAPIをサクッと作ってよ」と言われたのでシンプルなREST APIを作ってみた。 作ったものを渡すだけでなく作り方も教えて欲しいとのことなので、ここに記事として掲載する。少し手順書のような記載なため、初学者向けかもしれない。 Pythonと聞いて「Djangoでも使うか？」と思いつつも、よりサクッと感のあるフレームワークを探してみたところ FastAPIなるものがあり、今回はこれを採用してみた。 公式より引用 FastAPI は、Pythonの標準である型ヒントに基づいてPython 3.6 以降でAPI を構築するための、モダンで、高速(高パフォーマンス)な、Web フレームワークです。 FastAPI には Swagger UI と ReDoc の両スタイルのドキュメントを自動で生成してくれる機
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
