Re: なんで今さら帳票エンジンを新規開発しているのか
pdfmeとは Website: https://pdfme.com/ TypeScriptで書かれたオープンソースの無料の帳票エンジン。 テンプレートを使って宣言的にPDFを作成でき、サーバー、ブラウザどちらでも動作する。 2022年2月にbeta版としてリリースしてから現在 Version3で GitHubではStartが1500、npmではバラツキはあるが週間1万件くらいのダウンロードがある。 自分が把握しているだけで、世界中で採用事例があり、電子カルテ作成、工場の手順書作成、ECのカスタムパッケージ制作ソフトなど、すでにいろんなサービスに組み込まれている。 この記事ではどのようなモチベーションでpdfmeを開発しているのかということを説明したいと思います。 なんで帳票エンジンを新規開発するのか PDFファイルを作成・編集するという観点ではpdfkitという素晴らしいライブラリが20
無名のインディーゲーム開発者さんが4Gamerやファミ通などに初めてプレスリリースを送ってみた結果のまとめ
だらねこ@インディーゲーム開発中 @daranekogames 個人のインディーゲーム制作者。 ゲームブック風RPG #いのちのつかいかた 制作中。 -------------------- 「ゲームデザインの話に特化したTwitterコミュニティ」を作ってみました twitter.com/i/communities/… note.com/daraneko_games… だらねこ@インディーゲーム開発中 @daranekogames 【固定ツイート】 ゲームブック風マルチエンディングRPG #いのちのつかいかた の体験版を公開しました！ プレイヤーの選択で主人公の考え方が変わり、最終的な「いのちのつかいかた」でEDが変わるゲームです。 ▼Steamストアページ store.steampowered.com/app/1483370/ ▼DLsite dlsite.com/home/annou
技術的負債 - Martin Fowler's Bliki (ja)
ソフトウェアシステムでは、クラフト（出来の悪いもの）が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。たとえば、新機能の追加にかかる余分な労力は、負債の返済にかかる利子である。 あらゆるソフトウェアシステムには、タスクを実行するために必要とされる「本質的な」複雑さが一定量含まれている…… ……だが、ほとんどのシステムには「クラフト」が存在しており、理解を難しくしている。 クラフトがあると、変更するのに余分な労力がかかる。 技術的負債のメタファーは、こうしたクラフトを「負債」として扱う。変更に必要な余分な労力は、負債の利子の返済に相当する。 私のコードのモジュール構造が複雑だったとしよう。こ
【翻訳記事】デプロイ戦略の定義 - そこに仁義はあるのか(仮)
この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
GitHubリポジトリで8000スター獲得、人気OSS「Boostnote」オープンソース化の軌跡 - エンジニアHub｜Webエンジニアのキャリアを考える！
GitHubリポジトリで8000スター獲得、人気OSS「Boostnote」オープンソース化の軌跡 GitHubリポジトリで8000スターを獲得しているプログラマ向けノートアプリのBoostnote。グローバルな開発コミュニティを築き上げた経緯についてインタビューしました。 Boostnoteというアプリをご存知でしょうか？ こちらはElectronで作成されたデベロッパー向けのノートアプリ。実は海外ではとあることでとても有名なアプリなのです。 なんと企業が事業として開発しているアプリにもかかわらず、コードをすべてオープンソースとしてGitHub上に公開しているのです。海外を中心に注目度は高く、世界中のコントリビューターがBoostnoteに携わっています。現在、GitHubのスター数が8000を超える人気のOSSとなっています。 Boostnoteはどのようにグローバル展開とし、どのよう
「ちょうどいい」オートスケールを実現する「ロリポップ！マネージドクラウド」、研究・技術・開発が一体となった舞台裏に迫る！ - はてなニュース
GMOペパボが正式リリースしたばかりの「ロリポップ！マネージドクラウド」は、GMOペパボ研究所の成果であるFastContainerを基盤技術として適用し、新しいアーキテクチャを作り上げました。これにより、Webサイトの負荷増大に対応してスケールする仕組みを、エンジニアではない利用者でも簡単に扱うことができます。 ロリポップ！マネージドクラウド 使う人は楽になり、基盤の開発者にとっては挑戦となる新サービス「マネージドクラウド」について、開発チームメンバーに話を聞きました。 左から、小田知央さん（おだ・ともひさ、技術部 技術基盤チーム プリンシパルエンジニア）、瀧口舞さん（たきぐち・まい、ホスティング事業部ホスティンググループ マネージドクラウドチーム リーダー）、小山健一郎さん（おやま・けんいちろう、ホスティング事業部 ホスティンググループ マネージドクラウドチーム シニアエンジニア） ※
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
技術的負債の代替語でサービス負債という単語を考えてみた - 個人的なまとめ
きっかけはエンジニア内で技術的負債というのをesaにまとめてたときに、これをどうやってやっていけるのかなと思ってた。チームで仕事をしている以上、エンジニアだけではどうにもできない部分は確実にある。 もちろん他職種に丁寧に伝えるということは非常に大切なんだけど、まず「技術」というところで心理的ハードルを下げたかった。「技術」という単語が出るとどうしても「エンジニアだけのお仕事」という感じになってしまう。その時は他施策より優先度が下がることが多い気がする。 少なくとも自分がやりたい技術的負債の返却はサービスのためになるはずなので、サービス負債の返却という単語に置き換えてみようと思う。もちろんサービスを運用する上で、「望まざる状態でそうなってしまった」ものを「サービス負債」という括りにいれて言ってもいいと思う。結果的に運用が楽になってみんながハッピーになればいい。特に攻めの施策ばかりやっていて、
いい感じの開発者になる8つの心がけ - 思ったこと
これは @yoshuawuyts のブログから持ってきたもの。自分も同じことを常に考えていて、特に車輪の再発明、あるいは再構築を大事にしている。再発明といえども、決して同じ車輪を作ってるわけじゃなくて、気付いたら自分なりによりよい車輪を作ってることになる。その過程を楽んでいくうちに、好奇心の幅が広がり、プログラミングコミュニティ内で友達ができていって深く沈んでいけるものなんじゃないかなぁて思ってる。 というわけでざっくり翻訳したのをメモ： いい感じの開発者になる8つの心がけ 車輪を再構築する。多くの人は、それを止めてくるが、止めてくる人は再構築をしたことがないことが多い。彼らは、おそらく車輪について理解していない、かもしれない。きっと、新しい車輪が必要な際に新しい車をまるまる買うタイプの人。車輪の作り方を学んでいく。 既にある車輪を使うタイミングを知る。車輪を作る時間がないときもある。そこ
今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
二週間で簡単なインタープリタ言語を実装してみた (日記) - プログラムモグモグ
私は昔から言語処理系に興味があり、自分で言語を作ることを夢見てきました。 しかし、いざ言語を実装しようと思って言語処理系に関する本を読んでも何から手を付けていいか分からず、アセンブラもまともに読めないまま、数年が経ってしまいました。 大学時代は情報系ではなかったため、コンパイラの実験がある情報系の学科のカリキュラムを羨ましく思い、情報系の授業の教科書を手にとって見ても読む気が起きず、自分に作れるのは所詮、構文木をちょこっといじって変換するレベルのもの (例えばsjspなど) にとどまっていました。 そんな中、去年のRebuild.fmで、とても感銘を受けた回がありました。 LLVMのlinkerであるLLDを開発されているrui314さんの回です。 rebuild.fm セルフコンパイルできるC言語のコンパイラを実装するという話のなかで、インクリメンタルに開発する重要性について話をされてい
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
クラウドサービスを活用して README にバッジをペタペタ貼る - Qiita
最近の GitHub に上げてある OSS リポジトリには、README にいろんなバッジが貼られています。リポジトリに連携しているクラウドサービスのステータスを表すものがほとんどです。 自分は README にバッジを貼りたい派です。たとえば dtan4/terraforming だとこういう感じです。 最近はバッジの種類も増えているので、整理のためにもどういうのがあるかまとめてみようと思います。 自分がよく README に貼っているバッジ 自分が書く RubyGems については、以下の6個のバッジを必ずつけるようにしています。 Travis CI 言わずと知れた CI サービス。現在の master が CI 通っている (passing) かコケている (failed) かがわかります。リポジトリのメンテナンス状況を把握するのによいです。 クリックすれば、そのリポジトリのテスト結
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
エンジニア・Webデザイナー必読: アプリケーションを国際化・多言語展開する前に知っておくべきこと - Qiita
ちょろっとメモ。の割には長くなったけど、最後の方にいいことが書いてある。 ※技術英語や翻訳 Advent Calendar 2015に参加してみました。スレ違いだったらすみません。 追記: taka-oyamaさんの記事「多国対応ウェブアプリを開発する前に知っておきたかったこと」も参考になります。 追記: 「17ヶ国の多言語対応Tips」で当記事を紹介いただきました。素晴らしいスライドです。 追記: 「本当にあった怖い誤訳」によると、今でも機械翻訳をそのままウェブページで使っている自治体があるそうです。怖す。 追記: ぼくたちのかんがえたさいきょうのi18n国家 - Qiitaもどうぞ。 概要 Web アプリやモバイルアプリを問わず、アプリで当てたらそれ英語化だ多言語化だ国際化だ、となることは多い。しかしアプリの作りなどさまざまな原因によって、他所の国の言葉に翻訳してもらっても実は現地の人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロにしすぎた結果がこれだよ！
“エンジニア35才定年説に挑戦する” 開発チームのマネジメント
