TSKaigi 2024 のスライドです
note.com 僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました! 法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ(そうだ独立しよう)だけで起業して7年ほどひとり。今は2人体制になった。 会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません!沿わないと思う! 1. 決算処理は専門家に任せたほうが良い 自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。 6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。 決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れ
Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは? Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay
tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか? モジュール、依存、そしてカプセル化 モジュールをどう分割するのか? 簡潔さは力なり? 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは? 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
コードなしでWeb3コンテンツなどを開発することができるプラットフォーム・thirdwebの創設者であるadammaj氏が、「経験なしで2週間でゼロからGPUを構築した」と報告しています。 I've spent the past ~2 weeks building a GPU from scratch with no prior experience. It was way harder than I expected. Progress tracker in thread (coolest stuff at the end)👇 pic.twitter.com/VDJHnaIheb— adammaj (@MajmudarAdam) ◆ステップ1:GPUアーキテクチャの基礎を学ぶ adammaj氏はまず、最新のGPUがアーキテクチャレベルでどのように機能しているのかを理解しようとしたそうで
2024年4月5日、江崎グリコは基幹システムの切り替え後にシステム障害が発生し、同社や販売委託を受けている一部の冷蔵食品の出荷に影響が生じていると公表しました。ここでは関連する情報をまとめます。 障害後緊急対応するも在庫数合わず業務停止 今回システム障害が起きたのは江崎グリコの基幹システムで2024年4月3日の新システムへの移行に伴い発生した。物流、販売、会計などを一元管理するERPパッケージ SAP社製「SAP S/4HANA」で構築されており、「顧客への継続的価値創出を可能にするバリューチェーン構築と経営の迅速な意思決定を目的とした、調達・生産・物流・ファイナンスなどの情報を統合する基幹システム」と同社では説明している。障害原因の詳細は同社から開示されてはいないが、システム障害の問題個所の特定は済んでいる。なおサイバー攻撃によるものではないと取材に答えている。*1 システム障害の影響に
バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。 はじめに マイクロサービスとモノリス マイクロサービスとは マイクロサービスの利点 モノリスとは 単一プロセスモノリス モジュラーモノリス 分散モノリス テックタッチの場合 初期の頃の構成イメージ マイクロサービス切り直し前 特徴 モジュラーモノリス化 サービスの移行 別ドメイン境界でサービス切り直し イベントストーミング マイクロサービス切り直し後 DB 統合へ続く まとめ 参考 はじめに テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部の
Webページを作成する時に役立つ、HTMLをはじめとする必要最小限のファイルをまとめたシンプルな基本テンプレート一式を紹介します。 最新版は、最近の実装に合わせた設計にアップデートされました。 HTML5 Boilerplate -GitHub HTML5 Boilerplateの特徴 HTMLの基本テンプレート HTML5 Boilerplateの使い方 HTML5 Boilerplateの特徴 HTML5 Boilerplateは、Webサイトやアプリを実装するためのプロフェッショナルなフロントエンド用のHTMLの基本テンプレートです。 実践的な基本のテンプレート 200人を超える貢献者による10年間の分析・研究・実験を元にしています。 ブラウザの見え方を最適化 プログレッシブエンハンスメントを念頭において設計されています。 インクルード 推奨されるmetaタグやその他の利点を備えたH
はじめに 本記事ではレベルアップしたいエンジニアが読んでおくべきQiita記事を紹介します。厳選に厳選を重ねた43記事です。全ての記事を読んでおく必要はありませんが、ちょっとでも「分からないな」「興味あるな」など思ったタイトルがあれば読んでみてください。 次の4種類に分類して紹介しています。参考にしてください。 フロントエンド バックエンド インフラ・Linux周りの知識 その他 それでは、早速紹介していきます! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 フロントエンド まず最初はフロントエンドエンジニアに読んでおくべきとおすすめできるQiita記事を11個選びました!フロントエンドエンジニアとしての基礎が身に付く
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
様々な概念を表現する方法がプログラミング言語によってそれぞれ異なるように、React にも、理解しやすい方法でパターンを表現し高品質なアプリケーションを産み出すための慣用的な記法、ないしルールが存在します。 このセクションでは、自然な React コードを書くために従うべきルールを説明します。自然な React コードを書くことで、安全で整理されており、組み合わせ可能なアプリケーションを作成することができます。以下に挙げる特性により、アプリは変更に対して頑健になり、他の開発者やライブラリやツールと連携しやすくなります。 以下のルールは React のルールとして知られています。これらを守っていないならアプリにバグがある可能性が高い、という意味で、これらは単なるガイドラインではなくルールです。またこれらを守らない場合、あなたのコードは不自然で、理解や推測が難しいものになるでしょう。 Reac
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい!」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください! メガクラウドと特化型クラウド/ハイパーバイザーのSoC化/ライセンスとクラウドベンダー/イベント駆動型API/LLM時代のAIペアプロ力/生活必需品としてのGPU・NPU/Passkey/ウェブアクセシビリティ/リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS(Function-as-a-Ser
近年、AIの進化によりソフトウェア開発のプロセスが大きく変化しています。これまで手作業で行われてきた画面設計やプログラミング作業も、AIの登場により驚異的なスピードに進化しています。今回は、その中でも私が実際に使っている2つのAIツール、UizardとUI Sketcherについて紹介します。 なお、本記事では医師と患者を繋ぐマッチングサービスという架空のサービスを例に話を進めます。 Uizard: サービス概要からUIデザインを自動生成 Uizardは、画面設計作業を劇的に短縮する革新的なAIツールです。このツールを使えば、サービス概要を入力するだけで、わずか数分で美しく洗練されたUIデザインが生成されます。つまり、開発者は時間をかけてUIデザインを考える必要がなくなり、その時間を他の重要な作業に集中することができます。 Uizardの使い方 メニューから Generate with A
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性(ACID)というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが(クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている)、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。 けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。 よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。 例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。 そうすると、まず void 鳴く() { print("コケコッコー"); } のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。 いや、そもそも、コ
はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ? でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者(私)向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも?中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ! テーブル・DB設計は「属性」と「関係」の2つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない(しかも、ほとんど 1:N) これが極意だ!!! 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要
ネットスーパーシステムの決済ステータス表現 (状態遷移) は複雑だ。 その理由は要求要件が多いことに起因しているが、多いことが悪いのではなく、それに応えなければシステムとして真の価値を発揮できないからで。逆に問題解決できなければ、著しく利便性を落としてしまうので、必須要件という位置付けにある。 前提文脈を汲み取りづらいモデリングなので、問題解決例を示すのはあまり見かけないが、自分が考えた決済ステータス定義の答えを示す。 この内容は過去にブログや登壇で話した内容の延長でもあるので、過去の内容も参考にすると良いかもしれません。 「E-Groceryにおけるカード決済処理の難しさと設計戦略」 「ネットスーパーの買い物体験を支える工夫と決済機能実現の過程」 前提条件 注文から支払い完了まで時間差がある注文後に注文内容の変更ができる品切れが発生するケースがある販売員が注文内容を変更できる0円での支払
ひろみつ @bakueikozo 二児の父 。非納税王国民。 エンジニアリングよろず。 Youtubeチャンネル youtube.com/@bakueikozo nanaでピアノ弾いたり歌ったり nana-music.com/users/10349269 #ドラレコ 動画の転載、使用に許諾は不要 honeylab.hatenablog.jp ひろみつ @bakueikozo ダイソーで売ってたスマホ連携リモコン送信機を買ってみた。しかしELPAのやつで、普通はダイソーに売ってるようなものではなかったものなのではないかと思われる。スマホ連携リモコンなんていくらでもあるじゃんと思われるかもしれんが、これはローカル専用なのでインターネットに依存していないのだ pic.twitter.com/6avd4pNSGv 2024-04-10 01:39:17
This course is a deep dive into the world of PlayStation programming! We'll explore the PS1 hardware, understand its sub-components, and learn how to code games using MIPS assembler & the C programming language. We'll also learn how to use a PS1 SDK library paired with a modern development toolchain to be more productive and push fast polygons out of our console. We are about to enter the 5th gene
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
増田の指摘は的を得ていて、内燃機関から電気に変わって何が変わるのと言うのは仰る通りだと思われる。 それは何故かと言うと、現在のEVは、内燃機関の基本設計を電動化しだけだから。 PHEVなどはまだエンジン積んでるから仕方が無いにしても、EVにするんだったら、もうちょっとEVだからできる事を追求するべきではないかと思う。 各社色々なコンセプトカーが出ているが、実際にはなかなか普及しない。 インホイールモータこれがEVで望まれるイノベーションの最たるもの。今までの内燃機関だと、中央に大きなエンジンがあり、それをシャフトなどを通じて物理的に力を伝え、2輪もしくは4輪を駆動するという仕組みだった。 その為の機構が存在する事から、設計に制限がある。 これを、車輪の中、あるいは車輪のすぐ近くにモータを置いて、直接タイヤを回してやろうという考え方がある。これを「インホイールモータ」などと言う。 これにする
どういうこと?/TL;DR AWS → Cloudflareに移行したら費用が99%削減できました。 対象読者 今CloudFront + S3で構築しているけど転送量に困っている人 Cloudflare R2を検討している人 (CloudFrontとCloudflareをよく間違える人) はじめに 元々、動画CDNの構築はCloudFront + S3で構築していました。 この構成の場合、課金ポイントは主に三つあります。 CloudFrontのアクセス数に対する課金: そこそこ(多量ではない) S3の保管に対する課金: 200GB程度 CloudFrontの転送量(Egress)に対しての課金: 数TB そのため、毎回イベントごとにかなり費用がかかる状態でした。 動画の数もアクセス数もそこそこではあったのですが、動画特有の転送量が非常に多い… そういった状態でした。 導入前夜 この時はち
背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に本番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました
国土交通省の新技術研究として、「反転交差点」という先進的な交差点構造の本研究が始まりました。安全でスムーズな走行を実現する新発想の交差点、一体どんなものなのでしょうか。 アメリカの先進事例に着目 国土交通省が採択して研究される「道路に関する新技術」で、交差点の課題解決に期待される新たな技術が、研究スタートとなります。 「反転交差点」と呼ばれるこの新技術、いったいどんな技術なのでしょうか。実現すればどう便利になるのでしょうか。 交差点の信号待ち渋滞を解決する策としては「ラウンドアバウト」というものがあります。交差点を環状にすることで、南北側も東西側も交差点内で同じ方向へ進み、信号が無くても接触なく交差点を通過できるというものです。 しかしラウンドアバウトが機能するのは、あくまで通過交通が比較的少ない場合のみ。大都市部ではなかなか効果的に導入できません。 そこで他の事例として、可能性が提言され
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く