多摩美術大学が主催するビジネスパーソン向け講座、多摩美術大学クリエイティブリーダーシッププログラム（TCL）にCDO（Chief Design Officer）田中が講師として登壇しました。今回は特別...
デザイナーが経営に貢献する、ということ —— 多摩美術大学クリエイティブリーダーシッププログラム登壇レポート【質疑応答編】 | Visional Designer Blog
多摩美術大学が主催するビジネスパーソン向け講座、多摩美術大学クリエイティブリーダーシッププログラム（TCL）にCDO（Chief Design Officer）田中が講師として登壇しました。今回は特別...
Zennの技術まわりの質問があれば答えるよ
スクラップについてまだ周知していない段階で見つけていただきありがとうございますw （どうやって気づかれたのか気になります） 通知はけっこう苦労した部分です。仰る通りオブジェクトの種類（Article, Book, Comment, User）が多いんですよね。 Zennの場合、notificationというテーブルがあって、通知が必要になったタイミングでnotifiable_typeとnotifiable_idに通知に関連するアイテムの情報を入れています。合わせて通知の種類と、通知先のuser_idなども保存しています。 例えば「あなたの記事にコメントがつきました」と通知したい場合、こんなイメージでレコードが追加されます。 notifiable_type: "Article" notifiable_id: コメントがついた記事のID user_id: 通知先のユーザーID action:
保守性の高いソフトウェア開発のTips集
保守性の高いソフトウェアの開発に役立つ様々なTipsを書いた。 特定の言語にとらわれずあらゆる場面で役立つことを集めた。
Next.js+TypeScript+AWS Amplify+RecoilでToDoリストを作る
※投稿テストも兼ねてQiitaから記事をコピーしてみました 元記事 : https://qiita.com/Y_uuu/items/249dfcc794f101129b09 本記事ではNext.js+TypeScript+AWS Amplify+Recoilを使って、モダンなToDoリストを作る方法を紹介します。 Githubリポジトリを公開しますので、不具合や不適切な実装を見つけた場合はドシドシIssueかPull-Requestいただけると幸いです。 背景 私自身普段はRuby on Railsを使って開発しています。JavaScriptは正直まだ苦手です。 Railsは爆速でアプリを開発出来る点が魅力的ですが、一方でモバイルアプリとの連携やリッチなUIが求められる案件では、フロントエンドとバックエンドを分離した構成にせざるをえないケースがあります。 そのような構成だと、かえってRai
組織フェーズごとに考える、スタートアップのデザイナー採用 前編｜ウエタニマサユキ
突然ですが採用担当者のみなさん、デザイナー採用に苦戦した（している）、もしくは採用できてもチームに上手くフィットしなかった経験はありませんか？僕は結構あります。ここ数年間毎月のように「良いデザイナーを紹介してくれませんか？」と連絡いただくことからも、世の中の企業の皆さんも困っているのだろうなと感じています。 ただ、沢山の相談をいただく中でヒアリングを重ねてみると、ほとんどケースが「採用要件を整理せずに漠然と良いデザイナーを求めている」場合が多く、それが原因でつまづいている方が大半でした。その結果、例えば以下のようなパターンに陥っているケースをよく耳にします。 🙅あらゆるスキルを備えた人を求めていたが、どこにもいなかった 🙅何となく優秀なのは分かるが、明確な判断基準が無く採用できなかった 🙅採用はできたが、期待するパフォーマンスが出なかった デザイナーに限らず事前に要件をクリアにするこ
React Component 分業の覚書
フロントエンドを Next.js 化する機会が多くなってきた昨今。いざ取り組むにしても、スタイリング込みで実装出来るエンジニアが不足気味ではないでしょうか？また、縦割り分業している現場ではこれまで、マークアップ（フロントエンド）エンジニアが html + css を納品し、それを元にサーバーサイドエンジニアがテンプレートエンジンに組み込むという業務フローも少なくありませんでした。 この様な業務フローの場合、同じリポジトリで作業してもらうという事が難しいこともあります。Next.js 移行期のこれからも同様のことが多々起きると予想しており、完全分業するうえでの最適化を考える必要があります。この件について少しまとめたくなったので、メモ書きとして残します。 前提条件 以下の座組みは React Component 分業で最適だと考えている組み合わせです。マークアップエンジニアはこれまでと変わらず
分散化する世界で生じる混乱を乗り越える: 「仕事の解剖学」インデックス 2021 の分析結果
この記事は英語、フランス語、ドイツ語、ポルトガル語、スペイン語でもお読みいただけます。 世界中で 12 億 5 千万人にものぼる知識労働者 (ナレッジワーカー) の全員が、新型コロナウイルスによる影響を受けてきました。多くの人が短期間でリモートワークに移行したことから、コラボレーション用のツール利用の増加と、デジタルトランスフォーメーションの加速のきっかけにもなりました。 2019年、業務時間配分とその要因を分析するため、Asana は最初の「仕事の解剖学」インデックスを発表しました。昨春、私たちは「仕事の解剖学: リモートチーム調査」をリリースし、リモート分散勤務形態への急激な移行に知識労働者がどのように対応しているかについて検討を行いました。 本日、私たちは、前回の調査を下敷きにし、変わった点・変わらない点を勘案した分析結果の「仕事の解剖学」インデックス 2021 を発表します。この報
TypeScript で type と interface どっち使うのか問題
はじめに あくまで一個人の意見なので絶対的な解ではないというのと、どっちをデフォルトに選んでも普通にアプリケーション開発してて困ることはほぼほぼないと思うので、そこまで気を揉むことでもない、ということだけ最初に述べておいて意見をしたためます。 TL;DR アプリケーション開発では基本的に type でおk Declaration merging したい時だけ interface ライブラリ開発のような使う側で拡張したい(Declaration merging したい)時は interface とりあえずチームでどっちをデフォルトにするかは統一しといた方が気持ちいい type と interface の違い 機能的にはそんなに大きな違いはなく、個人的に判断に関わるのは次の3つかなと思います。 interface では Declaration merging がされる。type ではされない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
時間と場所にとらわれない働き方の実現に、ワーク&スタディ利用優先の「新幹線オフィス車両」をご活用ください。
Next.jsでAmplifyに入門する