「青銀行の勘定系をFirebase前提で構築できるか？」 - たなかこういちの開発ノート
Firebaseについて、事前知識 Firebaseとは、以下のような機能群を「Serverless」の文脈でバンドルしたものである。「Serverless」として、これらの統合管理コンソールの出来栄えが秀逸。 - Firestore ... Document-oriented KVS - Cloud Functions ... AWSのLambda - Cloud Storage ... AWSのS3 - Hosting ... Web Assetsのデプロイ先の提供、CDN展開サポート - Authentication ... ユーザー管理・統合認証サービスの提供 - Cloud Messaging ... iOS/Android/Web(JS)クライアントアプリへの統合プッシュ通知サービス - その他 いうまでもなく「Serverless」とは「サーバー運用・管理レス」の意味。まさに
ぼくたちのかんがえたさいきょうのi18n国家
本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — Masaki Hara (@qnighy) 2018年8月6日 長い前置き ソフトウェアのi18nは難しい。自文化では当たり前と思っていてハードコードしてしまった仮定が崩れて、大幅な再設計を余儀なくされるからだ。気づいて再設計できればまだ良
nginx で EU からのアクセスを拒否する - えいのうにっき
「あ、EUからのアクセスを拒否したいな......」と思うこと、ありますよね。私も今日、そう思いました。 私は趣味と実益を兼ねて（いるつもり）、いくつかのしょうもないWebサービスを個人で運用してるのですが、そこに対するEUからのアクセスを遮断したいと思い、それを nginx で対応してみたので、そのメモです。 手順 基本的にはこちら↓の知見の固まりを参考文献としています。 inaba-serverdesign.jp EU加盟国は、外務省のページ（EU加盟国と地図 第5次拡大｜外務省）によると以下の28カ国。 アイルランド イタリア 英国 エストニア オーストリア オランダ キプロス ギリシャ クロアチア スウェーデン スペイン スロバキア スロベニア チェコ デンマーク ドイツ（加盟時西ドイツ） ハンガリー フィンランド フランス ブルガリア ベルギー ポーランド ポルトガル マルタ ラ
Excelとパワポの知識だけで業務アプリを開発できる「PowerApps」とは
PowerAppsとは 「Microsoft PowerApps」をご存知でしょうか？ PowerAppsは、Excelのような関数とPowerPointのような操作だけで、コーディングすることなくアプリケーションが開発できてしまうサービスです。2016年10月に提供が開始され、日本語を含む42か国語に対応しています。 PowerAppsの最大の特徴は、OSやブラウザーの種類を問わず、どの環境でも使える点です。さらに、PowerAppsで作成して保存したアプリは、Windowsはもちろん、Mac環境のブラウザー（IE、Edge、Chrome、Firefox、Safari）で動きますし、iOSとAndroidなら専用のモバイルアプリが提供されています。PC向け、モバイル向けにそれぞれ別のアプリを作成する必要はありません。 PowerAppsでは、開発画面上でアプリUIの完成イメージを見ながら
タイムゾーン呪いの書 - Qiita
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
最新のウェブフロントエンド技術を無理してキャッチアップする必要はない - id:anatooのブログ
ウェブフロントエンド技術は変化が激しいと言われるけれども、多くの人にとって最新のウェブフロントエンド技術を無理してキャッチアップする必要は無い。以下理由。 ここでいう最新のウェブフロントエンド技術とは、新しいブラウザのAPIや新しいJavaScriptの文法や新しいフレームワーク・ツールなどを指す 今のHTML5はドキュメントを表現するプラットフォームだけではなくアプリケーションプラットフォームとしても機能するように進化をしている最中 だからアプリケーションプラットフォームとしての進化を支える新技術がたくさん出てきている 逆に言うと、アプリケーション(SPAとか)を書かない人にとってはキャッチアップする必要の無い場合がたくさんある また、それらのウェブフロントエンドの新技術を全てキャッチアップするのは基本的に不可能だと思う 自分はウェブフロントエンドやそれのパフォーマンスを専門の一つにして
webpack時代の終わりとparcel時代のはじまり - Qiita
設定不要のビルドツール parcelというビルドツールが空前の勢いでGitHubスターを集めており、リリース数日で5000スターを超えています。今日だけでも1000スター以上増えており、Googleなどの有名企業リポジトリ以外でこのスピードで人気がでるのは異例です。 https://github.com/parcel-bundler/parcel https://parceljs.org/ 実際に試してみたところ、これはwebpack一強時代を終わらせるレベルの使いやすさだと確信しました。 作者はAdobeのエンジニアで、その他著名エンジニアも続々と参加している様子です。 webpack疲れ webpackが出た当初、webエンジニアはgulp/grunt疲れの状態だったことを覚えている方もいるかと思います。 webpackの統合された設定ファイルは、タスクランナーで逐次処理していたものを
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SOLIDの原則ってどんなふうに使うの？
hirata.blog
Node.js を選ぶとき 選ばないとき