arm Mac と向き合う Web アプリケーション開発環境 しない話: Docker Desktop の課金回避 問題意識 Mac の CPU が arm になってしまった結果、以下のような問題がある JVM 系を中心に amd64 な Docker image が Mac で挙動が怪しい ネイティブ開発すっか!!となるとライブラリのバンドリングとかでおかしいことになりがち Ruby の nokogiri とか ネイティブだと古いものはわりと動かない そういう問題がなかったとして arm で開発したものを amd64 環境にデプロイするのはちょっと勇気がいる。 古い環境はアップデートせえやという話なのだが、リソース不足してるものはどうにもならず、結果として古い JVM 環境を延命させてたやつとかはまじでどうにもならなくなったりする。えてしてそういうものは皆さんの手元にあることでしょう。
ブックマーク / diary.ssig33.com (15)
-
raimon49 2021/12/28
-
認証自作、 Rails 、 Devise - Diary
認証自作、 Rails 、 Devise https://ockeghem.pageful.app/post/item/uQFX4oRNbnax82V これを読んで思ったことなんですけど、 Ruby On Rails 界隈では「認証は自作すべきではない、デファクトスタンダードの Devise を使うべき」という考え方が一般にあるように思います。 ではその Devise なんですけど、ドキュメントに以下のようにあります。 Starting with Rails? If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we ad
-
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 - Diary
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 Heroku を使うときに問題になるのは、データベースに何を使うかということです。 Heroku 標準の PostgreSQL Amazon RDS ClearDB (Heroku で MySQL を使えるアドオン) などが代表的な選択肢としてあります。ここで Heroku 公式が公開している RDS を使う方法についてのドキュメントを見ると、 RDS のインスタンスをインターネットに全公開して Heroku から接続せよと書かれています。 ネットワーク的な防壁がそろった環境が当然の現代においてこの方針はいかにも許容できないもののように思えます。しかし、ここで ClearDB と Heroku 標準の PostgreSQL について考えてみましょう。 まず ClearD
-
CircleCI (Performance Plan) vs. Github Actions - Diary
CircleCI (Performance Plan) vs. Github Actions 結論: CircleCI を買おう 現在ユビレジでは CI は CircleCI (Performance Plan)と TravisCI を使っていて、 CircleCI: サーバーサイド(いろんな言語がある) Web フロントエンド(Rails アプリのなかで webpack が動いていたり、 create-react-app で作られたペラっとしたものがあったりいろいろある) TravisCI: iOS アプリ というような感じで使い分けている。 Performance Plan なんだから iOS のも Travis から引っ越せばいいんじゃねえの?と思わんでもないのだが、 Travis の annual 課金がまだ残ってる iOS の CI と TravisCI と CircleCI に
-
-
cookpad TechConf 2019 にいってきた - Diary
cookpad TechConf 2019 にいってきた 面白かった、参考になったトーク スライドとかは Qiita に cookpad がまとめを作っています。 藤井 謙士朗 - 新規サービス開発を加速させる技術とデザイン このサービスについて、エンジニア視点で書かれた紹介記事はあって Firebaseでバックエンドエンジニア不在のアプリ開発 クックパッドが体感した、メリットと課題 これは結構面白い記事で、レスとしてこんなものを書いたりした。 KomercoではReactでWebの管理画面やティザー画面を作っていて、デザイナーがコードを書いているので、フロントエンジニアもいないんです と何事もないかのように書かれているところに実際何があるかをデザイナーが何をしているかというのをデザイナー視点で話していた。紹介されているツールや技法は非常に興味深い一方で、 これ簡単にまとめると、プログラミ
-
プログラミングが出来る - Diary
プログラミングが出来る と一言で言ってしまうのはあまりよくなくて、ある程度分割して考えるほうがいいと思っている。 自分が必要なものを作ることができる みんながもっている共通の課題のうち、自分の技術力で解決可能なものを見つけて、解決するプロダクトを作ることができる 同僚と協調しながら製品を作ることができる おおまかにいって「プログラミングが出来る」というのはこの3個のスキルに分割できるのではないかと思っている。そして、これらはそれぞれあまり関係がない。 自分の課題を高速に解決することができるが、それを製品や OSS にまとめてリリースすることは出来ない人 優れた OSS のポートフォリオを持っているが、同僚という立場の人と協調することはあまり得意ではない人 業務としてプログラミングで成果を出してきているが、別に趣味で自分のためになんか作ったりはしてない人 ゲームを自作しているが、別にそれで食
-
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる - Diary
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。 Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。 本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだい
-
まともな Slack クライアントとしての IRCCloud のご紹介 - Diary
まともな Slack クライアントとしての IRCCloud のご紹介 IRCCloudというサービスがあります。 IRC を使っていた人には tiarra + web クライアントみたいのをサービス化したもの、と言えば一言で分かってもらえるようなサービスです。 Android と iOS で動くクライアントもあり、とても快適です。 こちらのサービスですが、先月 Slack に(IRC 経由ではなく)直接接続する機能が実装されています。 We’re starting to test a new lab for subscribers today: First class support for Slack built with IRCv3. Use threads, reactions, avatars, message editing, attachments, custom emoji
-
UPQ 問題に関連して思い出したこと - Diary
UPQ 問題に関連して思い出したこと なんだけど、 ODM/OEM の多用による日本企業の空洞化が進んでいる分野というのは何も IT 業界や家電業界に限らなくて、ファッション業界もこれがすごい。というかこっちのほうが中国における産業の立ち上がりが早かったりもともと調達前提のビジネスモデルが発達していた分エレクトロニクス関連よりも状況が酷いかもしれん。 なんでもいいから適当な郊外型ショッピングモール 2,3 個を回ってみればいいのだが、特に区別もつけられないようなどうでもいい店が沢山あって、しかもどのショッピングモールに行ってもかならずほとんど同じような店が同じように入居している。 ではそういう店はいわゆるセレクトショップなのか?というと自前のブランドの商品を売っている。あれはなんなのかという、中国のファッション企業に「ブランドを一個お願いします」という形で発注するとブランドイメージを中国の
-
Docker で何が嬉しいのか - Diary
Docker で何が嬉しいのか というか我々がみな何を目指していたかというと、 Heroku の使い勝手を Heroku に縛られることなく得ることを目標にしていたわけです。もともと Docker 自体 dotCloud という Heroku クローンのようなサービスの実行エンジンから出てきたものだし。 ということで、 Docker に触れる前に Heroku にまず触れてみるといいと思う。というか大抵の人は Docker 使うより Heroku を使ってしまったほうが幸せなんじゃないですかね。僕は金ないので個人では Docker 使いまくってますが、所属してる会社には金があるので Heroku を使っている。 いずれにせよ、 Heroku に慣れてみると Docker やその周辺に散在する思想によって何が得られるかがはっきりとしてくる。
-
Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる - Diary
Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる 個人的なアプリをつくるとき、だいたい以下のような環境で作業しています WAF は Echo go-bindata をつかって各種アセットを Go のソースにくみこみ webpack をつかって JavaScript をコンパイル にたような環境の人はおおいのでは。 Go のアプリのビルドと実行は fresh でやってます。みんなつかってるとおもいます。 webpack にかんしては --watch オプションをつかうことで、物事がおこなわれていきます。 ここで問題になるのが webpack がコンパイルしたものをいちいち go-bindata で処理しないといけないということです。これを手動でやるのはいかにもダサい。ということでいろいろかんがえたりしらべたりしたところ、 on
-
セルフまとめ - Diary
セルフまとめ 力武さんが FreeBSD の開発者コミュニティは衰退して ports がやばいみたいな話書いたら、日本の利用者コミュニティの悪口みたいなエントリ上がってくるのまさに BSD 界隈のしょうもなさが象徴されていると思った — アラブ (@ssig33) January 11, 2017 力武さんが「FreeBSD は衰退しました」と言ったところ、佐藤先生がやってきて「俺はやっておるぞ、それはそうとして日本人はダメ」って叫び始めたという光景であり、本当に壮絶。 — アラブ (@ssig33) January 11, 2017 佐藤先生のエントリこの部分が一番やばくて、「老人ばっかだって力武さんはいうけど、若者もいるし、老人は沢山もどってきたし老人は沢山います」ってかいてある。力武さんの懸念が完全にただしいことがわかる。 pic.twitter.com/Bsqh3gUDp3 — ア
-
インフラエンジニアのいない会社で働いて 1 年半 - Diary
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
-
AWS CodeBuild をちょっと触ってみた - Diary
AWS CodeBuild をちょっと触ってみた フルマネージドのビルドサービス という触れ込みで、実際まあその通りなんだけど、これはあくまでもビルドツールであって CI ツールではない。出来ることはビルドだけ。 なので Amazon Travis 的なサービスではない。 AWS CodePipeline や Lambda や API Gateway などと組合せることで一気通貫の CI 環境を構築することはもちろん可能だが、大抵の場合において Travis に金を払ったほうがいいと思う。 Jenkins おじさんならぬ AWS CodePipeline が発生してしまう。 ビルドタスクが大量にあり Travis なり Jenkins なりのレーンが頻繁に逼迫してる会社ならばこれらサービスを使ってやっていくコストをペイできることでしょう。 一方で個人が Github の Private リ
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました