背景 つい先日、自分の担当プロダクトがひとまずα版リリースしました。 これまでのキャリアでは既存システムの拡張などが多く、ビジネスとしては自分で0からDBのテーブル設計をする機会がなかったため、キャッキャしながら今回初めてすべての設計をしたのですが、現実は厳しい。結構な数の失敗をしてしまいました。 この記事では、そんな「失敗したな〜」と思った設計についてまとめて、供養にしようと思います。 失敗したテーブル定義 というわけで、よかれと思ってテーブル定義してみたらつらかったことたち。 ネット広告系の会社なので、広告のデータ構造のサンプル多めです。 過度なテーブル分割 広告テーブル id name status bid url
こんにちは、sue445です。今期の嫁は キュアミルキー です。 tl;dr; GitLabとSlackを使ってる場合は https://github.com/sue445/gitpanda が キラやば〜っ☆ なくらい便利なのでみんな使ってください☆ 前置き ピクシブ社内での開発にはGitLab(オンプレ)とGitHub(GHEではない方)が使われています。 コードレビューの依頼などでSlackにPullRequestのURLを貼ることが多いと思うのですが、GitHubのURLをSlackに貼ったら勝手に展開されて便利ですよね。 GitLabにもOGPがあるのでpublicなリポジトリであればSlackに貼った時に展開されます。 しかし業務で利用しているGitLabのリポジトリは外部から容易にアクセスできなかったり、ログインしないといけないページなのでSlackにURLを貼ってもOGPが
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
↓↓↓最新の2021年版を作成しましたのでこちらもご覧ください。↓↓↓ hashimotosan.hatenablog.jp PDFはこちらからどうぞ[508KB] 2019年Pixel 3aやGalaxy S10など一通り新機種が発表されたので、2019年改めてブレイクポイントについて考えてみました(3年ぶり!)。 3年経ってほとんどのサイトがレスポンシブデザインになって、ブレイクポイントを少なく効率よく設定していく方向になっているのだと思います 前回、ブレイクポイントの設定はフレイムワークも参考に考えていましたが、 改めて考えてみると、モバイルファーストの観点からも640px/1024pxではないのではないかと感じました。 以下が3年前の前回の記事です。 いくつかブレイクポイントを調べましたが、 だいたい以下のような分け方が多かったです。 640px/1024px 480px/896x
YouTube’s free Playables don’t directly challenge the app store model or break Apple’s rules. However, they do compete with the App Store’s free games. The tech layoff wave is still going strong in 2024. Following significant workforce reductions in 2022 and 2023, this year has already seen 60,000 job cuts across 254 companies, according to independent layoffs tracker Layoffs.fyi. Companies like T
先日、また一年歳を取った。気がついてみればソフトウェア開発という世界に身をおいて、ずいぶんと歳月を重ねてきた。実に20年近い。この20年だけ取ってみても、様々な変遷を経て様変わりしたところと、大して変わらないところとがある。後者の一つが「チーム開発の難しさ」だと感じている。使う技術も、支える環境も、プロセスも勿論変わっているが、チーム開発が楽勝になったためしは未だ無い。変わらない難しさがずっとある。 思うに、人が他者との間でミッションを特定し、前提を把握し、お互いの強みと弱みを理解しあい、少しずつアウトプットを重ね、その過程で起きる不具合を適宜ふりかえりによって解消しながら、感情にも向き合いながら漸次的に物事を進め、成果を上げる...という行為がそもそもとてつもなく高度であって、上手くいかなくなる箇所がいくらでもありえる。 そうした人と人の相互作用を如何に上手く噛み合わせて、活動がなめらか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く