MJMLでhtmlメールを楽にいい感じに書くことができた話 - BASEプロダクトチームブログ
この記事は BASE アドベントカレンダー 13 日目の記事です。 はじめに こんにちは。 BASE BANK 株式会社 Dev Division にて Software Developer をしている永野(@glassmonekey)です。 普段はバックエンドエンジニアとして、Go/Python/PHP を主に書いてたりします。 最近はチームの分析基盤づくりとかもやってたりします。 そのことについて先日書いたりもしたので、もし良かったらご確認ください。 devblog.thebase.in 私達のチームでは、「BASE」でショップを運営しているショップオーナーが簡単に資金調達をできる「YELL BANK」というサービスの開発・運営しています。 thebase.in あるプロジェクトで、ショップオーナーへのコミュニケーション手段に HTML メール を新しく作ることになりました。その際に
TypeScriptのDIとTsyringeについて
DIとは DI（Dependency Injection）とは、日本語訳で依存性の注入です。依存性の注入と聞くと、依存性という抽象的な概念を何かに注入するような印象を与えますが、依存性という言葉自体は依存対象を表します。 DIにおける依存対象は、オブジェクトのインスタンスです。つまり、Dependencyはオブジェクトのインスタンスを指します。そして、Injectionは外部から挿入するという意味を持つため、DIはオブジェクトのインスタンスを外部から挿入するという事になります。 DIのコード DIの対応前後のサンプルコードで比較を確認します。次のコードは、ブラウザのコンソールに「Saved yamada!」と出力します。実用性はないコードです。 DI対応前 import User from './user' export default class Database { saveUser(
クラス設計本格入門 JJUGナイトセミナー 2021-6-16
イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパッケージ設計の実証済の形を覚えると、出発地点の設計が楽になる。 リファクタリングを積み重ねて設計を改善していく。
マイクロソフト、Progressive Web Apps（PWA）をWindows 10のデスクトップで実行可能に。Windows 10はWindows、Linux、PWA対応のプラットフォームへ
マイクロソフト、Progressive Web Apps（PWA）をWindows 10のデスクトップで実行可能に。Windows 10はWindows、Linux、PWA対応のプラットフォームへ マイクロソフトはWeb技術を用いてネイティブアプリケーションのように動作するProgressive Web Apps（PWA）を、WebブラウザのEdgeにとどまらず、Windows10のデスクトップ環境でも実行可能にすることを明らかにした。 Windows 10は当然のことながらWindowsアプリケーションを実行可能なOSですが、Windows Subsystem for Linuxが新たに搭載されてLinuxアプリケーションのサポートも進められています。 そしてマイクロソフトはさらにWindows 10の守備範囲を広げようとしています。次はWeb技術を用いたアプリケーション、「Progre
大規模プロダクトにおけるフロントエンドの1年間の変化 - Qiita
プロダクトに関わるエンジニアは40人近くいて、弊社ではフロントエンド/サーバーサイドといった明確な線引きがないため全員がフロントエンドに触れる機会が有りえます。開発チーム・コード共にそれなりに大規模と言えるのではないでしょうか。 やったこと モジュール間の依存解決 もともとRailsのSprocketsに沿ってjsを書いていたため、classは全て一つのグローバル変数に格納され、全てのjsが結合された巨大なapplication.jsをロードしている状態で、メンテナビリティやパフォーマンスに大きな問題を抱えていました。そこで去年よりWebpackを導入し、各モジュールの依存関係を整理してjsファイルを適切な単位に分割するようにしました。ファイル数が多いため段階的に作業をつづけ、今年ようやく全てのファイルの依存解決が完了することができました。 過渡期はWebpackとSprockets両方か
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Startup ゼミ 2021 秋期講習 / AWS Startup Seminar 2021 Autumn class - AWS Dev Day
CSSでテキストが1行に収まるときだけ中央寄せする