今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約（と可能なら余談）だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"（>= 2.1.3みたいなやつ）の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
アメリカ合衆国のとある政府機関への抗議のため、Chef関連のGemやGitHub上のソースコードを作者が削除した。 雇用期間に業務にてGemが作成されていたため、Chef SoftwareがGemの所有権を主張してGemを復活させた。 最終的には抗議行動に対してChef Softwareが折れることで決着が付いた。 現在Chef界隈が混乱している。 どうやら政治的問題のためにRuby Gemsに登録されたGemやGitHub上のソースコードが消されたらしい。 なかなか興味深い出来事で、なおかつ日本語圏に情報が出ていないので適当に記録しておく。 用語 Ruby：プログラミング言語の１種。日本においては超広範囲で使用されている超メジャーな言語。 RubyGems：Rubyにおけるパッケージシステム。他人のRubyプログラムやライブラリを簡単に取り込むことができる。 Chef: 構成管理ツールの
サマリ ハッキングAPI―Web APIを攻撃から守るためのテスト技法（2023年3月27日発売）を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃（テスト）を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。 本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。 重要事項説明 本書の監修者の一人（洲崎俊氏）と評者は知人関係にある 評者が読んだ書
良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
最近個人開発が熱い
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
Intro 前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。 これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。 その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。 ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期
https://twitter.com/clockmaker/status/1294213347898843136 これ見たけどやらかしが低レベルすぎやしないか、ヒューマンエラーのレベルじゃないだろ とりあえずRails触れますって奴ととりあえずNuxt触れますって奴がガチャガチャやった結果にしか見えねえよ API設計が無茶苦茶だし、コードレビューもろくに実施されてねえだろうし、試験の観点はどうなってんだよって話だろ やっぱ優秀なエンジニアなんてどこにもいねえんだな、安心して寝るわ
いまNext.jsで新規サービスを立ち上げるときの観点（Router・CSS・認証・監視など/2023年末）
免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく
2020年のフロントエンドエンジニアの技術スタックの一例 | potato4d D(iary) この記事と、TLで「これのバックエンド版が見たい」という発言に触発されたので書いてみます。口語体と文語体が入り乱れてるのは許してください。 冒頭のグラフはwakatimeで生成した今年1年間のプログラミング言語使用率です。2位はTypeScript、3位はTerraform、4位はYAMLでした。 立場 フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている1都合上、視野が狭いかもしれません。 公開している成果としては クラウドゲーミング最新開発事例 - #CEDEC2020 - Speaker Deck があります。 長年RubyとRailsを書いてきたので、技術スタックがそのあたりに偏っています。
まつもとゆきひろの履歴書｜仕事中にこっそり作ったRubyが世界を驚かせるまで #ぼくらの履歴書 - ぼくらの履歴書｜トップランナーの履歴書から「仕事人生」を深掘り！
※この記事は2019年8月に取材・撮影した内容です 私たちが使う便利なアプリの数々は、“プログラミング言語”によって作られています。言語の種類は数え切れないほど存在していますが、「多くの人々に利用されているもの」となると、ごくわずか。優れたプログラミング言語を生み出せる人物は、世界的に見ても一握りなのです。 その数少ない人物のひとりが、日本にいます。プログラミング言語・Ruby（ルビー）の作者である、ソフトウェア技術者のまつもとゆきひろ（ @yukihiro_matz ）さんです。使い勝手の良さや生産性の高さから、まつもとさんの生み出したRubyは世界中で高い評価を受け、まつもとさん自身も世界中のコンピュータエンジニアから「Matz（マッツ）」の愛称で知られるようになりました。 では、まつもとさんは戦略的に、現在のキャリアを築き上げてきたのでしょうか。その答えは「NO」です。むしろ、「自分
先日のApple Eventでも Mac Studio や iPad Air(第5世代) が発表され、いよいよ Apple M1チップ がデファクトスタンダードになったなあと感じています。自分もこれまで、業務用PCとしてMacBook Pro 2017を使っていたのですが、悪名高いバタフライキーボードの破損をきっかけに MacBook Air(M1) を購入してもらいました。 さっそく業務で使用していくためにセットアップをしたのですが、やはりIntelチップとの違いに戸惑ったので備忘録としてまとめます。この記事は元々社内のナレッジに書く予定だったのですが、自分自身QiitaやZennの記事にかなり助けられました。この記事も今後M1 Macをセットアップする人の役に立てばと思っています。 MacOSの基本的な設定を使いやすく変更する 購入したばかりのMacはDockに大量のアプリが登録されて
はじめに 本記事はアウトプットの心構えのカレンダー | Advent Calendar 2023の4日目の記事です こんにちは！！@Sicut_studyです！ 私はアウトプットの大切さを日頃から発信しており、実際にQiitaにたくさんの記事を投稿しています そんな中で、自分なりに高速に記事としてアウトプットできるフレームワークを使っているのでそのフレームワークについて紹介していきます アウトプットの大切さ まず言っておきたいのはアウトプットは質より量です 量が増えるとだんだんと質もあがります 私は駆け出しのエンジニアの方に普段から「100本記事を書けば人生変わる」と言っています。 そもそも世の中に100本記事を書いたことのある経験をしたことがある人はごく僅かです そんなごく僅かな人になれれば絶対人生が変わります。 多くの人ができないことをやり遂げられる。しかも記事という形で目に実力が見え
TL;DR GraphQLはクライアント側とサーバー側の双方の複雑化を解決するために利用されてる フロントエンドにとってGraphQLはHTTP上で動く信頼できる唯一のリソースとして振る舞う フロントエンドの状態管理のベストプラクティスとしてのApollo Client クライアントファーストなAPI, GraphQLはWeb APIのベストプラクティスになり得る クラシックアプリケーションを改修することなくGraphQLとモダンフロントエンドで今どきのアプリを作れる はじめに GraphQLは非常に良く出来たソフトウェア(の仕様)ですが、複数の側面を持つことからすぐに理解することが難しくまだ日本ではあまり受け入れられていない印象があります。GraphQLを端的に何と言われると "全てのフロントエンドのためのAPI BFF" なのですが、それだけで理解出来る人はなかなか居ないように思います
Twitterはサービス終了するのか？
「Twitter 終了」がトレンドに入った。そもそもTwitter は終わるのだろうか。 「ハードコア」のあとに先週、イーロン・マスクが「ハードコアに働けない人は退職を選んでくれ」と全従業員に最後通帳を突きつけた。それは、すでに半分以上の人員がレイオフされたあとだ。 しかし、レイオフと「ハードコアの踏み絵」の間には大きな差がある。レイオフはあくまで過剰（とイーロン・マスクが考える）人材を会社が選んで辞めさせるのに対して、今回は「自発的に」やめさせるきっかけを作ったということだ。 匿名アプリBlindの内部調査によれば、その結果「残った人材の75％」が離れることを選んだ。この数字が正しいかどうかは別にして（おそらく、もっと多くの人はしぶしぶ残ることを選ぶはず）、結果として相当な数の社員が、Twitter を離れることを選んだ。 Kylie Robison @kyliebytesWhat I’
バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
HTMXとは HTMXは、JavaScript を記述せずに、Ajax通信や高度なUXを実現できるライブラリ。 軽量 で 高速 で、既存のサーバーサイドのフレームワークとシームレスなやり取りができる。また、AJAX通信の発火、フォームの送信処理、DOMの更新などを既存のHTML要素を拡張するだけで可能とする。WebSocketやSSEにも対応しているので、チャットアプリなどにも適している。 2023 JavaScript Rising Starsでは、 フロントエンド・フレームワーク部門で見事2位に輝いた！(一位はReact、全部門だとshadcn/ui) 似たような機能として、Ruby on RailsのHotWireがあるらしい。 2024年はHTMXがくると言われているぐらい世界で騒がれているのだが、あまり日本では流行っていない。以下はGoogleトレンドで調べた結果である。 アメリ
おはようございますこんにちわこんばんわ。どうもぶたです。 以前、チーム内で「変数や関数の名前に妥協したくないなー。どうしたら上手く命名できるんだろう？やっぱり英語の勉強？」という話になったので、今回は名前付け、命名についてまとめます。 とは言え、自分自身多くの記事やドキュメント、書籍などに助けられているので、ほぼ紹介記事になります。 ただ、順番には気をつけた方がいいと個人的には思っています。 何事もそうですが、なぜやるのかを知ってからどうやるのかを学ぶべきかな、と。 例えば、「この単語とこの単語はニュアンスが違う」「そんな単語存在しないよ」「単数と複数が間違ってる」 そんなレビューを受けたことがある人もいると思います。僕も言われたことがあります。 そういった内容の記事もたくさんあります。僕も読み込んでいますしストックして参照できるようにしています。 それはそれで有用ですし、是非意識していき
良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士
Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービス
はじめに 本記事ではレベルアップしたいエンジニアが読んでおくべきQiita記事を紹介します。厳選に厳選を重ねた43記事です。全ての記事を読んでおく必要はありませんが、ちょっとでも「分からないな」「興味あるな」など思ったタイトルがあれば読んでみてください。 次の4種類に分類して紹介しています。参考にしてください。 フロントエンド バックエンド インフラ・Linux周りの知識 その他 それでは、早速紹介していきます！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 フロントエンド まず最初はフロントエンドエンジニアに読んでおくべきとおすすめできるQiita記事を11個選びました！フロントエンドエンジニアとしての基礎が身に付く
2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを全部試した
この記事は、Next.js Advent Calendar 2020 の6日目。 突然だが、2021年 は Fullstack Next.js 元年になる。 その理由として自分は以下のものがあると思っている。 ベストプラクティスとしての TypeScript のデファクト化 Next.js の Dynamic Routes による動的パス、 getStaticProps/getServerSideProps による使い勝手の向上 Vercel によるISRの発明 prisma の成熟 Vercel / Serverless / Cloudflare Workers / Cloudrun 等による Node.js サーバーの運用コスト減 参考: Frontend Study #1: 基調講演 - Frontend 領域を再定義する Blog - Next.js 9.3 | Next.js R
フロントエンドとSPA職人の目指したものの歴史と概略
年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、
自走プログラマー表紙 「自走プログラマー」という本が出ます！ この本は僕と清水川さん、tell-kさんで、株式会社ビープラウドの仕事として書いた本です。 自走プログラマーには僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウドのつよつよメンバーが何度も何度もレビューしてくれました。 僕は自走プログラマーを多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。 なぜかというと、普段、 僕（著者全員）が伝えたいこと・伝えてきたことを書いた本 だからです。 なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウドでは自走プログラマー（とPythonプロフェッショナルプログラミング）を読んでもら
僕らを縛る Node.js という呪いについて
これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存
バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした - ANDPAD Tech Blog
これは何 どのように技術選定してますか。よく聞かれます。SREチーム 鈴木心之介 です。しかし説明が難しい。難しいですが説明の助けになってほしく思い、技術選定を文書化した DesignDoc から1枚を公開してみました。 DesignDoc とは、ある程度の大きさや複雑さがあり一言で説明の難しい技術選定について、文書化したものです。これを通じて、技術選定をどのように行うか組織内に広めようとする試みです。2021年1月頃から始めています。 題材は、メール配信の冗長化をRailsで実現した tech.andpad.co.jp を、インフラ視点から技術選定した DesignDoc です。このメール配信SaaSの選定は2019年末頃に実施したもので、DesignDoc の取り組みを始めていなかった頃でした。時が経ち、ソースコードやSaaSの構成からは意図を読むことが難しく「なんじゃこれ」って質問を
こんにちは、Ubie(ユビー)株式会社でソフトウェアエンジニアとして働いている八木(@sys1yagi)です。 ソフトウェアエンジニア採用といえば技術面接ですよね。技術的な経験に関するインタビューや、コーディングテスト、技術課題の提出、ライブコーディングなどを行い、候補者の経験や技術力、技術の方向性やキャリア観などが自社とマッチするかを確認するというのが一般的かと思います。 Ubieでは、このような形式の技術面接をやめることにしました。自社とマッチするという点にフォーカスしたとき、これまでの技術的な経験や技術的な方向性は、Ubieで働く上でそこまで大きく関係してこないということがわかったからです。 技術的な詳細よりも、事業をつくることの経験や考え方を知りたい Ubieには２つの組織があります。Ubie DiscoveryとUbie Customer Scienceです。私が属しているUbi
（Railsのプログラミングスクールについての話です。あと自分はフィヨルドブートキャンプの卒業生で、バイアスかかってるかもなので差し引いてお読みください。） プログラミングスクールについてあまりいい話を聞きません。 炎上系のプログラミングスクールだけでなく、その他のプログラミングスクールについてもネガティブな話を結構聞きます。 正直自分もプログラミングスクール業界には良いイメージはないのですが、とはいえちゃんと探せば良いプログラミングスクールも（少しだけ）存在します。この記事はそんなお話です。 プログラミングスクールの理想と現実 プログラミングスクールの問題点は明確で、プログラミングスクールを卒業しても現場で働けるだけの実力がつかないということです。 こんなイメージです。 プログラミングスクールの理想と現実（字が下手すぎてすみません🙇） プログラミングスクールではRails周りの基礎を一
「NTT Tech Conference」は、NTT グループのエンジニア有志が開催するカンファレンスです。NTT グループ各社が開催するイベントとは異なり、NTT グループのエンジニアたちがやりたいこと・話したいことを通じて、エンジニア同士が技術交流するためのイベントです。ここで登壇したのは、NTTコムウェアの古西孝成氏。「SIerで幸せな技術キャリアを築くために」というタイトルで、SIerとして幸せなキャリアを築くための心構えについて、話しました。全2回。前半は特に若年層に意識してほしいことについて。 自己紹介 司会者：次のセッションは「SIerで幸せな技術キャリアを築くために」というタイトルで、NTTコムウェアの古西さんに発表をお願いします。古西さん、よろしくお願いします。 古西孝成氏（以下、古西）：はい、よろしくお願いします。NTTコムウェアの古西です。「SIerで幸せな技術キャリ
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
筆者はES6以前のVanilla JSがあまり好きではありませんでした。 そこで、バニラJavaScriptをなるべく書かなくていいように、2000年代を通じてさまざまなアプローチを追求してきました。最初はRJS（Ruby-to-JavaScript）、次はCoffeeScriptでした。どちらのアプローチも、バニラJavaScriptより楽しく書けるソースコードを、ブラウザが実行できるバージョンのJavaScriptへトランスパイルするものです。ある程度は、うまくいっていました。 とはいえ、これは明らかにその場しのぎの手段に過ぎず、ブラウザがより洗練されたJavaScriptを理解できる日を待ちわびていたのです。ただ、そんな日が来ることはなく、永久にその場しのぎでやり過ごすのかと思われる時期がしばらく続きました。 しかし、幸いなことにJavaScriptは改善を続け、2015年にはES6
こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して
※本記事は2020年4月に公開した内容です。 株式会社ディー・エヌ・エーのシステム本部CTO室の露木誠です。PythonやDjangoについて執筆した『パーフェクトPython』や『Django×Python』などの著書が技術系出版社から数冊出版されています。DjangoのAUTHORSファイルにも実は名前が掲載されています。 本記事では、Pythonを始めたいと思っている方向けに、Pythonの魅力をお伝えできればと思います。知っておきたいPythonの言語仕様や特徴的な考え方をご紹介しますので、参考にしてください。 Python関連のエンジニア案件を見てみる 自己紹介とPython、Djangoに関わる活動について ディー・エヌ・エーのCTO室に所属、元々は異業種からIT業界に参入 現在は、株式会社ディー・エヌ・エーのシステム本部CTO室で、エンジニア組織の課題解決を主な活動として、日
DXを大幅に低下させるDocker for Macを捨ててMac最速のDocker環境を手に入れる - Qiita
※DXはデジタルトランスフォーメーションではなくてDeveloper Experienceの方です 2020/05/26追記 https://qiita.com/nanasess/items/16ab9274c34bdc34e567 を使うことでVagrantを経由せずにDocker for Macの機能だけでMutagenを使うことができるようになりそうです。 パフォーマンスの測定はしていませんが、Docker for Macの設定のみでこの記事の手法と同等の速度が出るようになるかもしれません。 概要 Macでネイティブでの動作とほぼ同等の速度の安定したDocker環境を手に入れることができたので、その知見について公開します。 ものによりますが、最大10倍程度パフォーマンスの向上が見られました。 具体的な手法としてはVirtualBox + Dockerを用います。 設定は2ファイル50
たった数分で環境構築が完了！TypeScriptでWebアプリケーション開発ができるフレームワーク「frourio」が本当に手軽だった。 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
たった数分で環境構築が完了！TypeScriptでWebアプリケーション開発ができるフレームワーク「frourio」が本当に手軽だった。 こんにちは、エンジニアのづやです。 突然ですがエンジニアのみなさん、TypeScriptに触れた経験はありますか？ TypeScriptはGitHubが毎年発表しているランキングで今年4位に急上昇したくらい、もっともアツいプログラム言語の1つです。 出典：https://octoverse.github.com/ しかし、いざ試してみようと思っても、 フレームワークは何を使えば良い？ どうやって導入したら良い？ など、意外とハードルって高くないですか？ そこで「frourio（フルーリオ）」という画期的なフレームワークを見つけました。こういうのってある程度経験を積んだエンジニアでないと使いこなせない……というケースも多いですよね。 でもfrourioはそ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
Home | DBML
Intro DBML (Database Markup Language) is an open-source DSL language designed to define and document database schemas and structures. It is designed to be simple, consistent and highly-readable. It also comes with command-line tool and open-source module to help you convert between DBML and SQL. Table users { id integer username varchar role varchar created_at timestamp } Table posts { id integer
【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6
はじめに 何を書こうか迷ってたんですが、ちょうど副業始めて1年ほどたったので、どういうきっかけで始めたか、何をしてるのか、やってみたメリットなどを書いていこうと思います。 なぜ副業×AWSなのかというと、自分が副業をやっていく中で普段AWSに触れていることが強みになっていたので、単に副業だけじゃなくAWSも混ぜてみました。 これから副業を始めようと思っている人、特に本業で役割が変わってあまりコード書けなくなった人に参考になれば。 自己紹介 本業ではSREという部署でCloud Architecture Grpというチームを持っており、自社サービスであるCOMPANYのクラウドネイティブ化を推進しています。 主にクラウドプラットフォームとしてはAWSを利用しているため、日常的にAWSのサービスに触れる機会が多いです。 そんな本業の傍ら、3社で副業やってます。(20名規模ぐらいのベンチャー)
先日Herokuの完全有償化が発表されて以降、蜘蛛の子を散らすようにHerokuからの脱出が図られています。 そんなわけで概ねHerokuの代替となりそうな無料サービスを紹介していきます。 ほとんどの代替サービスは完全無料というわけではなく、機能の少ない無料プランと高機能の有料プランが存在します。 有料化前のHerokuと同じということですね。 各サービスについて、実際に使ってみたという参考記事を貼っておくので、実際の使い勝手等はそちらを参照してください(他力本願） Qiita内に使ってみた記事が見つからなかったサービスは、日本では人気がないのだろうということで選外にしました。 また概要は、各サービスの説明やドキュメントに記載されているものです。 代替サービス一覧 FLy Flyはグローバルなアプリケーション配布プラットフォームです。 Turbokuを使えばHerokuアプリをFly.io
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Semantic Versioningの闇 - knqyf263's blog
政治的問題のためRuby GemsとGitHubからChef関連の諸々が消えた件について
[書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法
本サイトの AMP 提供の停止とここまでの振り返り | blog.jxck.io
SEだが正直noteのやらかしを見てほっとしている
サーバーサイドエンジニアとして2020年に使った技術 | うなすけとあれこれ
M1 Macを購入したのでセットアップ＆zsh環境をいい感じにした - Qiita
アウトプットガチ勢が作った高速記事作成フレームワーク - Qiita
GraphQLの全体像とWebApp開発のこれから - Qiita
もうjsなんていらない！世界で流行っているHTMXについてまとめてみた - Qiita
「良い名前付け」の参考サイトまとめ - Qiita
レベルアップしたい人必見 Qiita記事43選 - Qiita
10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました - Make組ブログ
ソフトウェアエンジニア採用で技術面接をやめました｜sys1yagi
プログラミングスクールの理想と現実。あとフィヨルドブートキャンプについて - 猫Rails
SIerで幸せなキャリアを築くために 50歳の私が感じた、若手に意識してほしい3つのこと
JavaScriptのバンドルとトランスパイルが不要なモダンWebアプリ | POSTD
ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
Pythonを会得する考え方やポイント5選！ 『パーフェクトPython』著者が魅力を語る！ - FLEXY（フレキシー）
意識的に職位を下げる - id:onk のはてなブログ
(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
副業×AWSでわりと人生変わったエンジニアの話 - Qiita
Herokuの代替サービス30選、使ってみた参考記事リンク付き - Qiita