こんにちは、taroです！ 今回は、ベースマキナのTypeScriptのプロジェクトで不要なコードの検知・削除で使用しているKnipについて紹介します。 Knip とは Knipは、TypeScript/JavaScriptのコードベースの不要なコードを検出するCLIツールです。 以下が検出できる不要なコードの例です。 package.jsonのdependencies/devDependenciesの中で使われていないpackage exportされているがどこからもimportされていない変数、関数、型など 使用していないファイル その他、検出できる内容の一覧はこちらで確認できます。 またExperimentalな機能（2024年7月現在）として不要なコードの自動削除も可能です。 ちなみにTypeScript/JavaScriptの不要なコードの検出するツールではts-pruneも知ら

こんにちは。yebis0942です。GoとTypeScriptを書いています。夏祭りのおみくじで「待ち人来る」を引いたので、最近のちょっとした待ち事例についてご紹介します。 Goでタイムアウト時間を指定する関数を呼び出したとき、待機時間を0秒にすると何が起きるのか？という点が社内のレビューで少し話題になりました。 気になって調べてみたところ、同じ0秒のタイムアウト処理でも、内部の実装によって振る舞いが異なるケースがあることが分かりました。 よく見るタイムアウト処理 Go言語では、一定時間だけあるchannelを待つというタイムアウト処理は以下のように time.After() を使って書くことができます。 func timeAfter(c chan int, duration time.Duration) { select { case <-time.After(duration): //

ありがたいことに継続的にご利用者様の数・ご活用頂く業務の幅が増え、積み上がるご要望に日々追いつくべく開発に邁進しております。 今回は先日ベースマキナがリリースした「ロール機能」に付随するお話です。 ベースマキナでは、以前から管理画面上で呼び出す処理ごとに、ユーザーやユーザーのグループ単位で実行を許可する機能があるなど、ガバナンス要求に答える機能を揃えてきました。 今回修正が行われたのはそれとは別のレイヤーで、ベースマキナ上の管理者向けの設定（接続先のデータベースやAPIの情報や、処理の登録、ユーザー追加など）を行う権限を細分化 & グルーピング設定を紐づけられるようにした、というものです。 この機能は成果物で見るとシンプルなのですが、権限管理にまつわる設計・開発はいつも魔物に立ち向かうようなもので、混迷を極めます。 そして、こと管理画面開発となるとその難易度は他の開発よりも高い、というのが

ポエムです！ 長いのでまとめローコード・ノーコードという言葉の括りは大きな意味をもたず、「プログラマブル」という表現が妥当 プログラマブルな基盤を作って売ることは、課題解決の幅を最大化する。複利でのアセット積み上げが可能で、ひいてはコンパウンド・スタートアップの地盤を作りやすい利点がある この基盤は最初から覚悟を決めて作らないと、後追いで構築するのが難しいため商材としての希少性が高い プログラマブルな基盤は、売り手に高い課題探索・抽象化能力と海外サービスへの強い関心が求められる こうした基盤を事業として成長させることは、将来「Sell work, not software」の時代が来たとしても生き残る手立てを作る最良の手段になりうる まとめても長いですね… はじめに皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋と申します。 現在弊社では、ソフトウェアエンジニアの

皆様、ChatGPTでCode Interpreterの機能がリリースされましたがお使いになりましたか？ 僕は大変有りがたーく日常使いさせて頂いており、活用方法について各方面のご意見を伺いたいですが、その話はさておき… こうした劇的な開発体験の変化が予感されると、度々繰り返される議題の１つが「エンジニアやコードの不要論」かと思います。 私自身がローコードツールを提供している会社の経営者なのですが（ヒューマンエラーを減らせる管理画面構築SaaS「ベースマキナ」をよろしくお願いします！）、この類の議論の盛り上がりと日頃情報を追っている最新のツール群との間を照らすと、ギャップを感じます。 端的に言うと、少なくともここ１年くらいで新しく登場するデベロッパー向けのツールを見ていると、コードが不要になる場面が増えると思いきや、逆にコードをしっかり書くツールが増えてきたな、という印象を持っています。 D

まとめプログラミングの未来では、最適化と自己修復がキーワードとなり、エンジニアは検品作業が主な役割になると考えられます。 ローコードツールは、否応なしにLLMとの共存を求められ、対応できなければかえって足かせとなってしまい淘汰されるでしょう。 そして、ローコードやノーコードの概念が意味を持たなくなるでしょう。 しかし、未来はシステムのチューニングに焦点を当てた業務になり、チューニングのための学習データを幅広に獲得できる現在のローコードプラットフォーマーは、きたる未来に備えて強力な武器を持てると考えられます。 ごあいさつこんにちは！ ローコードでかんたんに管理画面が立ち上げられるSaaS「ベースマキナ」を運営している、 株式会社ベースマキナの代表取締役社長の髙橋と申します。 サービスページはこちらです。管理画面の開発工数でお困りの方、手前味噌ながら大変便利なサービスに進化してきているので是非

今年の夏にGo言語に以下のようなプロポーザルを出していたのですが、それが先ほど承認されました。標準パッケージの関数追加になります。 proposal: bytes, strings: add ContainsFunc · Issue #54386 · golang/go · GitHub Go言語のstringsパッケージとbytesパッケージには、文字列から文字や部分文字列を探す関数がいくつかあります。 探す文字の位置を返す関数、最後から探す関数、そういう文字が含まれるかどうかを返す関数を表にまとめると、次のようになります。 Find what? Index* LastIndex* Contains* substr string Index(s, substr string) int LastIndex(s, substr string) int Contains(s, substr s

GraphQL における N+1 問題の解決の機構として Dataloder と呼ばれるものがあるが、Go でこれを行うときは gqlgen + graph-gophers/dataloader という組み合わせがよく使われるようだ。後者は gqlgen の公式ドキュメントからも参照されているので、gqlgen を使っていれば自然とそうなりそう。 このへんの話は 【GraphQL × Go】 N+1問題を解決するgqlgen + dataloaderの実装方法とCacheの実装オプション - LayerX エンジニアブログ などに詳しい。 さて、この dataloaders ってのを普通に使ってコードを書いてみるとわかるのだけど、ロードのためのキーとして string を、ロードされた結果として interface{} を返すような実装になっている。つまり実際にデータベースにアクセスするよ

こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開

要するに起業して、サービスを作りました。同志を募集しています。 長い自分語りなのですが、サービスを公開した直後の人間の所信表明として生暖かく読んでもらえればと思います。 サービスを公開しました先日、これまでステルスで開発・営業活動等をしていた社内管理画面作成サービス「ベースマキナ」を一般公開いたしました。 思った以上にお問い合わせであったり新規のご登録を頂き、感謝の想いに尽きません。 開発者一同が「きっとこの基盤なら自分達を含めWeb企業でサービス開発をしてきた方が何度も車輪の再発明をしてきた管理画面を作らなくて済むようになる」と信じて、持てる限りの技術でプロダクトを作っています。 公開時にも以前から相談させて頂いたエンジニアや事業者の方々にシェアいただき、一定話題に挙げていただきました。 ただ、自分としてはSaaSというサービスの提供方式やエンジニア文化を大事にするというのは手段で、本当

こんにちは。HRBrainでインフラエンジニアをしている間野(@mano_0307)です。 今年の5月にインフラエンジニアとして入社しました。Kubernetesを使っている弊社で、Kubernetesをまったく触ったことのない私のような人間がインフラエンジニアになれるというのが弊社の素晴らしいところです。合言葉は「トライドリブン」。日々トライができる素晴らしい環境です。 Dev環境という各社共通の悩み 多くの会社で何かと困っているのがdev環境なのではないかと思います。 dev環境今日も空いてないよ・・・フルリモートでどうせバレないし、寝ちゃお あれ？久々に使ったdev5環境がうまく動かないよ。・・・(数時間後)あー、最新のmasterがrebaseされてないからAPIのinterface変わってんじゃん！うわー寝よ・・・ そろそろdev環境増やしたいな・・・でも、あの設定も複製しなきゃ

単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理

結論 端的に言えば5W1Hを徹底した文章を書くと良いのでしょうね。 エラーログの責務 日々漫然とエラーログを出力していませんか？私はしがちです。 エラーログの責務が何かを考えたとき、エラーの原因特定だという認識におそらく齟齬が生まれる方というのは少ないのではないでしょうか。 ただ、テストを書いたりクラスの責務を考えながらコードを書くのを面倒に感じる場面があるように、習慣づけていないとエラーメッセージを丁寧に推敲することなく書いてしまったり、そもそも書き漏れのケースがあると思うのです。 とはいえ、エラーメッセージをいい加減に書くとデバッグコストが上昇するし、コンテキスト依存のバグを特定したいのにリクエストに紐づいた値が全く出力されていないと、途方に暮れるだけで根本対応ができずじまいになってしまいます。 よくないエラーログ 「うちは一応エラーログを書いているよな」と思うチームでも、ログを見てす

この記事は、Merpay Tech Openness Month 2020 の6日目の記事です。 メルペイでBackendエンジニアをしている柴田（@yoshiki_shibata）です。この記事では、Go言語のtestingパッケージに用意されている並列化の機能について説明します。 Go言語では、テストコードを作成するためのtestingパッケージが用意されています。一般に開発するソフトウェアの規模が大きくなるに従って、作成されるテストコードの量も多くなり、すべてのテストが終了するまでの時間も長くなっていきます。特に、データベースへアクセスするようなテストでは、データベースへの通信時間がテスト時間の多く占めますので、テストコードを逐次実行するよりは並列実行することで、テスト時間を短縮できます（厳密には用語「並行」ですが、t.Parallel()メソッドの説明なので、この記事では用語「並列

技術選定について最近の私生活や労働を通して考えたことを、つらつらと書き下した文章（ポエム）です。 他者に伝えることではなく、頭の中におぼろげに存在する考えを言語化して客観視することを目的に書いた雑記なので、 誰かにとっては当たり前なことも、誰にも当てはまらないことも書いてあるかと思います。 またここで述べることは、こうやって書き下した時点での僕の考えに過ぎないので、明日僕は全く別の考えを持って行動しているかもしれません。 いわばこれは僕の思考のスナップショットです。 諸々、ご容赦ください。 技術選定そのもの ソフトウェアの開発においては、どこからが開発者の作るものの責務であり、どこからがその下のレイヤの責務であるかを（あるときには能動的な思考より、またあるときには受動的な思考により）明確にする、という知的活動を繰り返していくことになります。 この営みは、開発するソフトウェアに関する前提を定

良い本を読んだ次の日の朝というのは気分が最高に良くて、なんだか大型のアップデートが終わったPCを再起動させるような、そういう気分になります。 元同僚で日頃から尊敬しているDMMの松本さんがさらに尊敬する人物として挙げられているのを見て、「俺より強いヤツに会いに行く......」と意気揚々に購入したのですが、素晴らしい書籍でした。配り歩きたくなるレベルというのは頷ける。 この本には良いところが２つあって、１つは小野さんのご経験の描写の距離感、もう１つは今まさに読むべきという旬の度合いでした。 まずご経験の描写の距離感という話ですが、経験談をベースにした本というのは、自分が最前線で戦っていたときに得た学びを書いているものなのか、それとも陣頭指揮をしていて「俺が部下を操作したから勝てた」というのを、現場の苦労は数行で済ませて美談にまとめ上げたものかに収束します。 そして得てして後者が多いのだけれ

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

tl;drNext.jsはv9.3.0以降Initial Loadingの扱いが変わったクライアント側ではApolloを利用することができるが、Authorization Headerを設定するなら一工夫必要SSR時にはfetchによるシンプルなAPIリクエストをすると良い昨今のWebフロントエンド昨今のWeb開発において、React、TypeScriptとかのベース知識は当然として、やはりNext.js(あるいはNuxt.js)のような、SPA/SSR両方のニーズを汲み取りながら、dynamic routingを提供してくれたり、ビルド環境を高速に整備してくれるフレームワークが重宝されるようになってきていると感じます。 また、Reduxもアリですが、スキーマ駆動開発が推進できるGraphQL、特に尋常じゃなくステート管理が用意になるHooksとApolloクライアントの組み合わせは、フロ

コロナウイルス感染予防のリモートワーク １週目が終了しました。さきほどアナウンスがあり、3月まで継続とのこと。いい話ですね。 個人的には、毎日リアルタイムのマッピング情報やら海外のトップニュースでコロナの話が出ているのを見ていると、「大丈夫大丈夫〜リモートワークとかPR要素でしかないでしょ〜」とか言ってるのは流石に油断しすぎでは？と思ってしまいます。 ちょっと前にフレックスに変わったくらいの勤務形態なので、チームにリモート勤務のノウハウは全くなかったけど、VPNの設定などの周知が行き届いててスムーズにやれてると思います。 ということで、その辺の管理周りの知見は別の方に任せるとして、働く身としてよかったこと悪かったことを書きます。前提として、私の職種はソフトウェアエンジニアです。 よかったこと1. MTG回数の減少 これは賛否両論ありそうですが、個人的には良かった点です。 MTGは基本的に洗

まとめ・リファラル採用への熱量は思ってるより差が明らかに出てくる ・リファラル採用を後から促進しましょう、は果たしてうまく回るのか（回らないと思う） リファラルこわいリファラル採用は怖い。絶対に敵に回したくない企業が何社かあります。 最近幸いにもお誘い頂く機会が増えて思った事なんですが... 給与などの必要条件を満たした上で、ビジョンでグイグイ目線上げている経営者、その理念を理解した上で行動している採用担当者が時々いて、十分条件が充実している企業が増えてきたという実感があります。 大きな企業でリファラル採用しようとしても、「人手が足らないので来て欲しい」という色合いが強すぎると魅力的に響かないと思っています。 一方で、ベンチャーでも資金調達を済ませてビジョンや採用候補への理解に熱心な人がリクルーティングしていると、正直働いてみたいなと思う気持ちも湧くし、同時に採用広報とかをちゃんとやりまし