はてなブックマーク

本日のテーマは「フレームワークでは脆弱性を担保する素晴らしい機能があるのにどうして脆弱性が残ってしまうのか？」です。先に答えを言ってしまうと、勝手に安全になるものと、フレームワークでは担保されておらず、開発者自身が意識しないといけないものがあるからです。開発者が意識すべき脆弱性を見ていきましょう。 『よくわかるPHPの教科書』を検証してみる 『よくわかるPHPの教科書』で紹介されているソースコードの一部を実際にデモで動かしてみます。 // ここまでで、認証済みであるこの検査が済んでいる $id = $_REQUEST['id']; // 投稿を検査する $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id)); $record = mysql_query($sql) or die(mys

2023年11月29日に開催されたAWSのカンファレンスイベント「AWS re:Invent」で発表されたAIチャットサービス「Amazon Q」がついに2024年4月30日に一般公開されました。 AWS announces general availability of Amazon Q, generative AI-powered assistant https://www.aboutamazon.com/news/aws/amazon-q-generative-ai-assistant-aws Amazon Q Developer, now generally available, includes previews of new capabilities to reimagine developer experience | AWS News Blog https://aws.am

このページの概要Ubieに転職して2年4ヶ月が経った。たまにはpublicに何か書いた方がよいよねということで、タイトルの件について書くのがこのページ 知り合いやコミュニティ、あるいはカジュアル面談でよく聞かれるtopicになる 最近読んだ「エンジニアリングマネージャのしごと」（以下、EM本）と関連する部分が多いのでところどころで引用する ちなみに自分はこの辺の制度設計にはほぼ関わってはいない（アンケートに答えたぐらい） Ubieについて会社紹介 → Ubie株式会社_会社紹介資料 症状検索エンジン「ユビー」を運営する医療系スタートアップです お前誰よhamaknのresume（public公開版） サーバサイド寄りのエンジニアです 最近は、症状検索エンジン「ユビー」の、個人の健康データを用いたパーソナライズの仕組みや、ユーザへの通知の開発や運用をしています 過去のUbie関連の記事 [2

はじめに 本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。 gihyo.jp 本記事で一番伝えたいこと データモデリングについての考えが深まるぞ 開発者が読むともっと役立てることができると思うぞ QAエンジニアである私が読んでも役立つぞ 読み始めてすぐに「良い買い物だった」と思って思わずポストしている様子 目次 はじめに 本記事で一番伝えたいこと 目次 本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい SoAとSoMという整理 「残」という概念 データベース設計とは違う「データモデリング」という考え方 QAエンジニアとして、業務に役立てそうなこと

初めてのプレスリリースを出した結果 なんとご連絡した6メディア中3メディアに掲載いただけました！ その時に行ったこと、注意したことをまとめていきます。 掲載いただけたメディア ・電ファミニコゲーマー/1300リポスト/4300いいね ・プレスリリースから1時間以内に掲載、Xに投稿する際に動画を使用 ・Game*Spark/21リポスト/83いいね ・電ファミニコゲーマーさんの次に掲載、Xに投稿する際に画像を使用 ・AUTOMATON/260リポスト/880いいね ・Game*Sparkさんの次に掲載、Xに投稿する際にGIFを使用 ・ファミ通 ・土曜日に送って次の営業日である火曜日に掲載、Xに投稿する際に動画を使用 プレスリリースを書く時に参考にしたサイト こちらからテンプレートをダウンロードして、使用させていただきました。 プレスリリースの内容は、こちらのテンプレートを自分のゲームの内容に

米カリフォルニア大学サンディエゴ校に所属する研究者らが発表した論文「Taking ASCII Drawings Seriously: How Programmers Diagram Code」は、ソースコード内で使用するアスキーアート（ASCII art）を収集し分析した研究報告である。 ▲ソースコード内で活用されたアスキーアートの一例 keyboard_arrow_down 研究背景 keyboard_arrow_down 研究内容 オープンソースのソフトウェア開発では、プログラマーがコードの中にアスキーアートを使って図を描き、アイデアを視覚的に表現することがよくある。アスキーアートはコードや自然言語では表現しにくい概念を視覚的に明快に説明でき、またコードよりも詳細度は低いものの、コードを理解するうえで「サムネイル」のような役割を果たす。 こうしたアスキーアートは、実際のソフトウェア開発

エンジニアの間では発売から瞬く間に広まった本書ですが、まだ読んでない方々向けに本記事を書いてみました。要約なので、ここは重要だなと感じたポイントに絞って本記事に記載します✏️ 概要 まず結論からいうと、仕事の進めかたや捉え方という点でとても学びのある良書です。すでに多くのエンジニアには知れ渡っていますが、もっともっと知れ渡って欲しい本です。 内容としては、著者の牛尾さんがアメリカのMicrosoft社（Azure開発）で得た経験がそのままに書かれています。最初はアメリカのエンジニアに劣等感を感じていたようですが、その理由を言語化して、実際にどうすれば彼らと肩を並べるエンジニアになれるかが書かれています。 また全体的にアメリカのエンジニア思想を爆推ししているので、こっち系の思想が好きな人は一瞬でハマると思います。私もどちらかと言えば圧倒的にこっちのタイプですが、読むときには偏らないように中立

はじめまして。2023年2月に入社したQAエンジニアの大出です。 前職はフリマアプリを開発する会社で約8年QAエンジニアとして働いていて、TalentXで初めてtoBのサービスのQA業務を行うことになりました。 入社前の状況 やったこと 新規開発の検証 テストプロセス改善 テスト計画の作成 ドキュメントの整理 バグチケットの整理 ドッグフーディング 採用 まだやれてないこと 終わりに TalentXは2015年にMyReferというサービスをリリースして以来、2023年2月に自分が入社するまで社内にソフトウェアテストを専門に行うメンバーは在籍しておらず、開発エンジニアが自分達で全てテストを行っていました。 そういう状況で私が入社してから約1年間でやってきたことを振り返りたいと思います。 TalentXの開発に興味がある人や、ソフトウェアテストを専門に行うメンバーが居ない会社でこれからQAエ

ヘンリーで SRE をやっている id:nabeop です。 昨年からオフラインイベントも活況になってきています。登壇の準備段階や登壇時に気をつけておきたいポイントについてまとめて、技術勉強会 (ギベン)1でエンジニアが社外登壇するときに気をつけたいことの Tips 集みたいな感じで発表してみました。このときの発表の評判がよくて社外向け版もつくってみない?という声があったので書いてみました。 弊社では Google Workspace を使っているので、Google スライドで資料を作成し、社内向けの資料の保存場所は Google Drive を使うというワークフローで考えます。 登壇準備 社内の外部登壇記録に登録しておく スライドで使用するロゴなどは敬意を持って使おう Google スライドで PDF 化を考慮したフォントを使う Google Drive は社内で共有しやすい場所を選択し

はじめに おはようございます。Watanabe Jin(@Sicut_study)です。 今回は「やる気がない日も机に向かうべきか」について書いていこうと思います！ ぜひやる気が出ないときはぜひ試してほしいことを書いています。 毎朝5分で読める 朝5分で読めるシリーズは平日7時にエンジニアの方が読んで何か気づきが与えられるような記事を投稿しています。 よければ@Sicut_studyのフォローを宜しくおねがいします！ またスタエフでも毎朝6時58分に同様のお話をしているので、耳で学習 したい方はこちらもお願いします やる気がないときも勉強すべきか？ 私の運営するプログラミングコーチングJISOUでお悩み相談がきました。 「やる気がない日でもすこしは机に向かったほうがいいですか？」 まずは結論からいいます。 日頃から、プログラミングの勉強を頑張っているのであれば やる気のない日はやらない。む

GitHubは米国時間4月29日、「GitHub Copilot Workspace」のテクニカルプレビュー版の提供を発表した。 GitHub Copilot Workspaceは、同社開発者向けAIツール「GitHub Copilot」ネイティブの開発者環境。2023年の同社カンファレンス「GitHub Universe」で披露され、コードについてブレインストーミング、プラン、構築、テスト、実行を自然言語で可能にする。 開発者にとって最大の壁は、ほとんどの場合、作業の始めにあるとGitHubの最高経営責任者（CEO）であるThomas Dohmke氏は述べる。大型プロジェクト、機能リクエスト、バグレポートの最初のステップで壁にぶつかることが多いが、それは、どう始めたらよいかが単に分からないためだという。GitHub Copilot Workspaceは、作業の起点となるリポジトリーやIs

絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の

「ビットキー知ってます！〇〇カンファレンスにスポンサーされてましたよね！」 「この前ビットキーの方が登壇してるのみました！」 「あー、あのスマートロックのとこ！」 初めまして！株式会社ビットキーで技術広報活動を担当しているパウリです！ 一昨年あたりからビットキーは技術広報活動に力を入れており、私が参画した2023年5月からさらにその活動量は増加しました。 その結果として、ありがたいことにスカウト返信や面談の際に、冒頭のような反応をいただけるようになってきました😊 本記事では事業会社において、技術広報活動の中で重要だと思った 「空振りをし続けること」 についてまとめてみました。 はじめに いかに自社の技術力が優れていても、適切な広報が伴わなければその価値を知ってもらうことは難しいでしょう。 ここで重要な役割を果たすのが 技術広報活動 です。 技術広報は、ただ製品を宣伝するだけではなく、エン

こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。 本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。 なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。 チームの紹介 PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。 担当しているプロダクトとプロジェクトは、SmartHR Plu

{ "scripts": { "_docker": "docker run --rm --ipc=host -v $(pwd):/workspace mcr.microsoft.com/playwright:v$(node -e 'console.log(require(\"./package.json\").devDependencies[\"@playwright/test\"])')-jammy", "_test": "playwright test", "_test:ci": "CI=1 playwright test", "_test:u": "playwright test --update-snapshots", "serve": "ts-node -r tsconfig-paths/register server.ts", "test": "pnpm run _docker

この手の話には、私を含め多くのエンジニアが食傷していると思いますが、重要なトピックなので無視できません。ここ数ヶ月の目立った動向を確認し、それを基にソフトウェアエンジニアの仕事が今後どうなるかを浅薄ながら検討していきます。 Devin - 初のAIエンジニア2024年3月、ほぼ無名だったCognition社の動画が注目を集めました。動画では"First AI Software Engineer"というタグラインのもと、私たちエンジニアの作業風景と同じように、AIがエディタやコンソールを操作し、ブラウザでサードパーティのAPI仕様書を探し、ビルドエラーからバグを修正し、Webアプリケーションを実装していく様子が見られます。 Devinは、SWE-benchというプログラミング性能を測る指標で、Claude 2やGPT-4を上回ったとと宣伝されています（下図）。またCognition社はPet

Androidスマートフォン（スマホ）／タブレットでは、標準のままだとシステムの状況を確認したり何らかのデバッグ情報を表示したり、といった機能が少ない。Windows PCで標準装備のソフトウェアツールを使ってこうした機能を利用したことがあると、Androidには不自由を感じてしまうこともある。 実は、Androidにも標準でこうした機能が搭載されている。それは「開発者向けオプション」「開発者モード」「開発者オプション」などと呼ばれている。 しかし、それらは隠されていて、普段は利用できない。本Tech TIPSでは、この機能を「オン」「オフ」する方法や注意点を説明する。 開発者向けオプションを「オン」にする 開発者向けオプションを設定するためのメニューは「設定」アプリにある。ただし、標準では「設定」アプリに表示されないため、そのままでは「オン」にできない。 これを表示させるには、「設定」ア

「1000回遊べる」をキーワードに、長きにわたってファンに愛されてきた『風来のシレン』。2024年1月25日には、ナンバリングタイトルとしてはじつに14年ぶりとなる最新作『不思議のダンジョン 風来のシレン6 とぐろ島探検録』（以下、『6』）を発売した。 ダンジョンで倒れてしまうと、持っていた道具をすべて失ってしまったり、レベルが1に戻ったりとシビアなゲームシステムながら、絶妙な難度でくり返し遊びたくなる魅力が詰まっており、シリーズ最速で出荷本数20万本を達成するなどヒットしている。 本稿では、ゲーム発売後に行った開発者3名へのインタビュー記事を掲載。発売後だから聞けるさまざまな開発秘話に加え、現在開発中となる追加コンテンツに関する情報などをお届けする。 記事中にはゲームの攻略情報も小ネタとして掲載しているので、現在プレイ中の人こそ必見！

はじめに よくQiitaでおすすめアプリとかの記事を見かけますが 逆に使わなくなったアプリの紹介記事ってなくね？ と思い今その勢いで本記事を書き進めています。需要があるかはしーらないっ。 本記事では、今年で4年目のエンジニアが作業効率を追い求める中で淘汰されていったアプリたちを紹介します。 ちなみに当方Macユーザです。 エディタ Visual Studio Code 3年目くらいまでは結構使ってました。 settings.jsonやkeybindings.jsonをdotfilesで管理してみたいなこともするくらいには使ってました。 が、何かのタイミングでvimに興味を持ち、vimを使いはじめてから徐々に使わなくなってゆきました。 vimに興味を持った最初の頃はVSCの拡張でvimがあったので、それを使ってました。 VSCでvimの操作を再現できる拡張です。 しかし vimと言えば学習コ

はじめに 昨今「開発生産性」についての話題をよく目にします。 生産性が向上することで悪いことは無いので、様々な組織の事例が公開されて業界全体に知見が共有されていくことはとても素晴らしいことだと感じています。 話題のこちらの本 「世界一流エンジニアの思考法」にもとても大切なことが書かれておりますし こちらの記事も参考になりました。 それらを踏まえて個人的に生産性向上のベースになる大切なことだと思っている 「即レスの大切さ」 について書きたいと思います。 これまでやってきたお仕事 ツールアプリの新規事業責任者（3年ほど） 全体3名の少人数チームでスタート 私（責任者+PdMの役割）、エンジニア1名、デザイナー1名 最終的には30人前後の組織の事業部長 ゲームアプリのマーケティングマネージャー（5年ほど） 組織全体としてはビジネスサイド20名、エンジニア5名、デザイナー5名ほど 会社経営（4年ほ

すごいエンジニアになるためのマインドセット2つ目は「あらゆる責任を引き受ける」 2つ目に田中氏が大事にしているマインドセットは、米国の起業コンサルタントであるダン・ケネディ氏の「人生のコントロールをしたかったら、責任を引き受けろ」だという。 人生にはさまざまな判断がつきもの。しかし、会社の中でも意外と判断していない人は少なくない。その理由は「責任を取りたくないから」だと指摘する。しかし、逆に言えば責任を取る意思があれば、どんなことでも自分で決められる、判断できる、自分でコントロールできることを意味する。 つまり、責任を取れる人は、判断できる人であり、指示されたこと以上のことができる。すると、どんどん仕事ができるようになり、プロアクティブに動いて仕事をこなせるようになっていく。一方、責任から逃れようとする人は、常に言われたことしかできなくなり、さらに力もつかず、言われたことすらできなくなって

バックエンドなくてもフロントで完結するライブラリ作りました。サンプルでTodoアプリにしました See the Pen KiZooNa.js TODOs by John Doe (@04) on CodePen. ソースコード 使用方法 使い方はLaravelのクエリビルダーとまったく一緒です。Laravelのpluck()やcount()やinsertGetId()など全部使えます！ <html> <body> <script src="https://github30.github.io/KiZooNa.js/KiZooNa.js"></script> <script type=module> const db = new DB({ url: 'http://localhost/sql-injection.php', dsn: 'mysql:host=127.0.0.1;dbname=

新人が1on1に来ない。その原因を考察する。 ここで出てくる新人の情報は以下である。 年齢: 30代前半 エンジニア歴: 5年 入社して半年 1on1を行うに至った経緯: 1年前、私と同じ時期に入社した同期Aが退職した。 詳細はよく分からないが、どうやらチームの先輩の1人と相性が悪いとの事だった。 尚、Aが退職したのは上記の理由だが、退職したいからこれを名目上の理由にしているのであって、原因は他にある可能性はあるが、この際それは考慮しない。 会社の人員構成: ほとんどがエンジニア歴10 ~ 20年のベテラン。平均年齢は30代後半。 Aは30代前半。 周囲の反応: Aが退職を告げた時、周囲はうろたえた。事前に相談は無かったし、特に問題はないように思われていた。 何より30過ぎた社会人は、問題があれば自分から話して来るという思い込みが、既存社員にあったもしれない。 年齢は関係あるか: ないと考

イオンスマートテクノロジーでスクラムマスターを担う翁長のインタビュー記事です。フロントエンド開発チームは、開発内製化を進めています。翁長はそのiAEONアプリ開発チームにアジャイル開発導入をすべく、初期から携わってきました。誰もアジャイル開発の経験がない中、どうやって体制をつくっていったのか？イオングループ全体にも広げたいという熱い想いも語ってくれました。

こんにちは！ 2023年度エンジニア新卒の、吉田です。 株式会社リクルート 新卒エンジニアコースでは、部署への配属前に、BootCampと呼ばれる新人研修を行っています。 本日は2023年度の研修の内容を、実際に受講した新卒の立場から紹介させていただきます。 研修の内容については毎年反響をいただいていますが、今年度も一段と進化し、より充実した研修でした。 ページ下部に研修資料を公開していますので、ぜひ研修の雰囲気を感じ取っていただけると嬉しいです。 研修の概要 エンジニアコースの新人研修は、配属後にスピード感を持って成長できるようになることを見据え、 「さまざまな技術領域の講座を受け、興味関心を広げて、知らなかった好奇心に出会う」 「現場で求められる『仕事への取り組みスタンス』をつかむ」 「気軽に相談できる仲間（同期）をつくる」 の３点が目的とされています。 今年度は、入社前に行われたスキ

「Vim」が愛され続ける理由と、サンプルで学ぶ使い方：TechTargetジャパンエンジニア読本集 「Linux」の標準テキストエディタとして根強い人気のあるのが「Vim」だ。初心者にとってはなじみにくいVimを、使い勝手の良いツールにするためのコマンドやカスタマイズを学ぼう。