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

皆様、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

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

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。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クライアントの組み合わせは、フロ

この流れです。 前提基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。 ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。 また、大学に入ってから学習を始めましたし、当時はドットインストールが出始めたくらいで、基本的には書籍で勉強していました。大学では授業でFORTRANの授業を取りました。内容は意味わからなかったので同級生に寄生してました。 Progateとかプログラミングスクールとかには頼ってませんでした。無かったので...。なので、「幼少期からBASICを触

当ポストはGo Advent Calendar 2019の5日目の記事です。基本ポエムを書いていて技術記事を書く感覚が鈍っていますが頑張ります。 今回はGoでheadless browser（Chrome）を用いた、動的な画像生成を行うというテーマで書きたいと思います。 なぜ画像生成したいのか？人はなぜ画像を生成したくなるのでしょうか？僕は漫然と画像を生成するのは、時間に限りがある身としてはよくないな、と思います。ということで理由が必要なのですが、最たる例はOGP画像の生成とかじゃないでしょうか？ あるいは任意のLGTM画像を生成したくて、文字を画像にかぶせたり、インスタグラムVer1.1みたいなサービスをローンチしたい時に、フィルター加工を実装したかったりするかもしれません。 Goで画像生成するには？Goで画像生成する方法に関してはこの１、２年でpo3rinさんや僕がしばしば登壇して解説

基本忙しいな〜と思いつつ、幸いにも仲良く仕事ができてることが多い。その理由を考えてた時に気づいたことをまとめたのがこの文章になる。ここで言いたいことはつまり、「機能を削ることはユーザーと開発チーム双方にとって、恐らく各位が考えている以上に良いことだ」ということだ。 なお、サムネは「機能を削ぎ落としていく過程はまるで彫刻製作のようだ...」と一瞬考えた時に程よい画像をとってきたのだけれど、単純にキモいなと思ったのと、的を射ているようで射てない気がしたし、プロダクト開発も彫刻もそんな知らないので、可及的速やかに忘れることにした。 いかにしてチームは殺伐となるかリリース間際やプロダクト開発が長期化すると、えてしてチームは殺伐としがち。自分が関わったチームでのプロダクト開発では、半々で殺伐なシーンと平和なシーンだった。 殺伐な開発は、その後チームの人間関係に消しがたい遺恨を残し、結果退職や倒産とい

tl;dr・Goの依存性注入は普通に行われるが、DIツールはまだ観測範囲では浸透していない。 ・直近出たGoogle製Go向けDIツール「Wire」はシンプルなAPIやツール作成で有用だが、依存オブジェクトの設定が複雑化すると表現性に限界がくる ・Goにおいて、DIツールはある種のフレームワークと認識して慎重に採用すべき前提：Goの依存性注入と課題Goのコードを書く際、特に一定規模を超えたAPIを書く際は、依存するオブジェクトというのが増える。DBクライアントやロガーや各種ビジネスロジックを呼び出すサービス層などがそれに該当する。 レイヤー化されたパッケージ構成の下、こうした依存オブジェクトをトップダウンに注入していくやり方は見通しがよく、テスト時にモックのAPIクライアントを差し込みやすかったりと、テスタビリティを向上させる。ざっくり依存性注入が行われるようなレイヤー化された構成で、なん

コード書いてる時、わからないことをわかるのは大変。（わかりますね？） 知らん単語とか出てくると、うーんと唸りながら調べるけど、やっぱわからない。そういうことが多かった時期は、コードを書くにしても手が進まず結構辛かった覚えがある。 最近だと、静的解析、CQRS + ES、DIツールの理解などを進める際に時間を消費してしまった。が、前に比べてわからないことにキャッチアップする手順が画一化されつつあり、頭を抱え続ける時間は減ったように思う。 大体いつもどんな風に進めてるか、２通りに分けて明文化する。 参考資料が多く存在する時静的解析とかはこういうケース。すでに参考資料がたくさんある場合は、整理されてるものなら幅広く集める。 1. 公式ドキュメントを集める 2. 良さそうな解説資料・ウェブサイト・書籍などをリストアップする(10件くらい) 3. 汎用的かつわかりやすい解説と、自分の得意な言語でそれ