Railsなプロジェクトにといてdependabotを利用してgemを定期的に更新する場合の運用方法・パターンについてまとめてみました。 dependabotでgem更新を管理する理由 個別gemごとにみた場合、バージョンアップでバグ修正や機能追加が期待できる プロジェクト全体でみた場合、Ruby / Railsのアップグレードに備えて日頃からgemのアップグレードを行っておく必要がある どこかの時点でまとめて上げる方法もあるが、バージョンが一気に上がるとその都度の動作確認が大変になりがち。特に脆弱性修正が発生した場合に芋づる式に複数のgemについてバージョンアップする作業はシビアな時間との勝負になりがち。 よって、特に自社サービス運営の場合は日常的にgemを上げていくことが望ましいことが多いでしょう。一方で、受託開発の場合は保守契約の内容次第で対応は変わってくると思います。 PR毎にやる
コンウェイの法則は、コンピューター科学者のメルヴィン・コンウェイが提唱した法則です。 システムの開発には組織・メンバー同士の密なコミュニケーションが不可欠なので、関係性の遠い組織間を密に統合するようなシステムを開発するのは非常に難しい。よってシステムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう、というわけです。 コンウェイの法則が提唱された1968年は、1963年に世界初のGUI（グラフィカルユーザーインターフェース）であるSAGEというアメリカ空軍の防空管制システムが発明された5年後にあたります。「UIデザイン」というデザイン領域が存在することすらほとんど認知されていなかった時代でしょう。 ですが、コンウェイの法則は当然システムの一部であるUIデザインにも大きな影響を与えます。この記事では、良いUIデザインをつくるためにどんなチームを目指すべきか、またその中でU
お金の健康診断の資料を (パワポがあまりにも無理すぎて）Figmaで作り直したんですが、tweetしたら需要がありそうだったのでベースとして使えそうなテンプレート配布しますね。 figmaでサービス資料作るとこういう感じ。一覧性もあるし、誰でも編集できるし、メンバーが気軽にコメントも書ける。オンラインで共有もできる。便利では？？？ pic.twitter.com/lG7GZewSko — 山下 あか理 (@AkrYmst) July 19, 2019 ・同じソフトウェアを使うことでデザインファイルと連携しやすい ・デザイナーが見た目を調整しやすい ・ソフトウェア自体が無料、GoogleFontが使える ・オンラインで共有可能、コメントによるレビュー可能あたりの理由が導入の根拠です。大したファイルではないのですが、何かの役に立てば幸いです。
Next.jsのサンプルリポジトリを眺めていたらInferGetStaticPropsTypeというものを見つけました。これを使うと、getStaticPropsでreturnされた値をもとに、Pageに渡されるPropsの型を類推してくれます。 ↓ ドキュメントはこちら これまではこんな感じで書いていた これまではPropsの型宣言を自分で書いていました。 import { GetStaticProps } from 'next'; // 👇 type Props = { posts: Post[] }; export const getStaticProps: GetStaticProps<Props> = async () => { const { posts } = await getPosts(); return { props: { posts, }, revalidate:
感想です。 何をしたか 現状でBlitz.jsで本番サービスを運用できるかの調査。 Railsで運用している本番サービスの一部機能を、3日間ほどかけて移行を試してみた。 結論 (Railsの主戦場でもある)新規事業開発の文脈でのクイックな立ち上げを想定するなら、本番運用するにはまだ厳しい。 特に、RailsユーザーとしてはActiveRecordがないのが厳しい。 開発効率そのものはRailsと比べて多少落としても、Railsよりもスケーラブルで型安全に開発したいなら、割と良い選択肢に思う。 もろもろ可能性は感じるので、引き続き応援していきたい。 良かった点（＝Blitz.jsに興味を持っている理由） 型安全な開発 サーバーもフロントも全てが型に守られた開発、そしてIDEの恩恵を受けられるのは、いうまでもなく心地がいい。 型は補助輪のようなものなので、ユーザースキルが高ければ必須ではないく
ユーザビリティというのは普遍的に重要なデザインテーマの一つですが、一方でユーザビリティへの関心は、UXが普及して以降、徐々に失われている印象があります。例えば、ユーザビリティがテーマにした書籍のほとんどは2000年代の刊行で、少なくとも日本国内において、2010年代以降に発刊された書籍は僅かです。 実際、Googleトレンドで2004年からの「ユーザビリティ」と「UXデザイン」の検索動向を比較しても、「UXデザイン」が2010年以降に増加傾向であるのに対して、「ユーザビリティ」は2000年代前半をピークに下降しています。 「UX」だと別の意図の検索を含むため、あえて「UXデザイン」で比較していますが、ここにデザイン文脈で使われる「UX」を加えると、「UX」は「ユーザビリティ」を確実に上回っているはずです。 だからといって、2010年代以降にユーザビリティが重要でなくなったわけではありません
デザイナーの池田です。 ベイジといえばBtoBサイトの印象があるかもしれませんが、実は採用サイトも多く手掛けています。 採用サイトの案件では、ほぼ確実に撮影が発生します。そのため、担当するデザイナーは、撮影にも立ち会い、ディレクションする必要が出てきます。 撮影といっても、何を撮るかによって撮り方も進め方も変わりますが、採用サイトを含む採用目的の撮影となると、以下の条件が前提になってきます。 モデルは社員（プロのモデルではない）モデルは通常、仕事の合間に撮影に参加日常的な服装やメイクオフィスなどの職場が撮影場所非日常的な演出より日常の再現求職者に職場のリアルな雰囲気を伝えるのが一番の目的になるため、日常の自然な風景をカメラに収める必要があるのと、モデルが一般の会社員になるため、スムーズかつ短時間で撮影が済むようにナビゲートしなければなりません。 本記事は、私たちが採用サイトの撮影で学んだ、
2020年はコロナウイルスの流行をきっかけに、これまでの働き方を見つめなおす企業も多かったのではないでしょうか。かくいうベイジも本格的なテレワークを導入しましたが、慣れるまでは懸念事項を多く抱えていました。そのうちの一つが、「雑談がなくなる」ということです。 テレワークの特長として、コミュニケーションの合理化があります。一人ひとりが離れた場所で働くことで偶然のコミュニケーションが生まれにくくなり、業務連絡といった目的と意図が明確な会話だけが残るようになります。オフィスに出社していた時のような、気軽な雑談が一掃されてしまうのは容易に想像できました。 雑談は、労働生産性の向上に直接影響を与えるものではないかもしれません。しかし、雑談がなくなると人間同士の精神的な繋がりは希薄になります。それによって誤解が増え、仕事が困難な局面に陥った時の心理的クッションが失われてしまう、といったリスクが生まれか
4/26 に発売されます！ 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー！」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を
最近 React コード生成機を作っていて「一番文句言われなさそうな React コンポーネントの書き方ってなんだ…？」と改めて疑問に思ったので考えてみました。 結論から言うと以下の形をデフォルトにするのが良さそうかなと思いました。 function vs. アロー関数 -> アロー関数 型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する return を省略可能な時省略するか -> しない props を destructure するか -> しない派だったけどした方がいい気がしてきた const Hoge: React.VFC<Props> = ({ title }) => { return ( <Fuga title={title} /> ) } ちなみにですが、大事な前提として TypeScript を使うことを前提としています。(型
Myersらの1992年の調査によれば、一般的なグラフィカルユーザインタフェース（Graphical User Interface; GUI）アプリケーション開発でコードの48%、実装時間の約半分がユーザインタフェース部分に割かれているといいます。それだけユーザインタフェースの設計は難しいプロセスなのです。 ユーザインタフェース設計で役に立つ基礎理論や評価手法、支援ツールは、人とコンピュータの関係をよりよくしていく学問 Human-Computer Interaction (HCI) で研究、開発されてきました。ただ、こうした知見を体系化されたかたちで学習する機会は（とくに国内では）必ずしも多くありません。 このWebページでは、自分が研究者になるにあたって知っておきたかった基礎的なことを、参考文献を挙げながら紹介します。想定している読者層は HCI を専門にする学生や、ユーザインタフェー
新R25でブランド戦略を担当しているムロハシと申します。 このnoteは「明日から真似できる“ブランディングを意識した”記事サムネイル画像のデザイン」と題しまして、新R25を通しての、サムネイルのブランディングデザインについて書いています。 まず、デジタルメディアサービスのデザインを大きく分けると以下の2点があるかと思います。 1.【UIデザイン】 アプリやwebサイトの見た目の印象や使いやすさを設計し、同時に情報を整理して開発しやすいデザインを追求する。（アニメーションやインタラクションなどの動きのあるデザインも含む） 2.【グラフィックデザイン】 サービスの世界観からプロモーションにいたるすべてのビジュアル、ロゴなどをつくり、目的に合わせたグラフィックデザインに落とし込む。（モーションデザインやテロップデザインなども含む） （※もちろんこれだけではないですが）では、これらのデザインを「
2020年1月にSPEEDAのCDOに就任しました。3ヶ月後の4月からは、SPEEDA、FORCAS、INITIALといったB2B SaaSプロダクトを担当していたデザイナーがひとつの組織に集まり、B2B SaaS事業のCDOになりました。（ちなみに、速攻で育休取得したので、本当にカオスのスタートでした汗） あれから、約１年。多くの失敗を重ね、私たちのデザイン組織が成長していく中で、学び得た実践知をシェアします。新年度に、新しい組織を立ち上げ成長させていく方々のヒントになれば幸いです。 結論：組織デザインするための５つの要素１：組織が目指す理想の姿「ビジョン」 ２：ビジョンによる「コンピテンシーマップ」 ３：コンピテンシーマップによる「目標設定」 ４：目標設定による「フィードバックサイクル」 ５：フィードバックサイクルによる「自己認識力」組織の責任者は、一人ひとりのメンバーと向き合いながら
目次 目次 はじめに オススメの学習コンテンツ 【AWS SOME DAY】 【AWS ご利用開始時に最低限おさえておきたい10のこと】 【AWS Black Belt Online Seminar】 【AWS Hands-on for Beginners】 【ハンズオンチュートリアル】 さいごに はじめに 「AWSに興味はあるけど、何から始めたらいいか分からない」 そんな方々に向けて、たくさんあるAWSの学習コンテンツのうちのいくつかをまとめて、紹介していきたいと思います。 本記事で紹介するコンテンツは全てAWS公式のコンテンツとなっています。 オススメの学習コンテンツ 【AWS SOME DAY】 aws.amazon.com 概要 AWSの基本を1日かつ無料で学べてしまう太っ腹なトレーニングです 費用 無料 特徴 通常は会場でのリアル開催のようですが、2021年現在は「AWSome
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コ
こんにちは、かしまです。 先日、嫁と一緒にコンピテンシー診断を受けてみたらバチボコ当たりすぎてて、2人で結果を見せ合いながらニヤニヤしちゃったのでおすすめさせてください…！！！ ◆コンピテンシー診断はコチラから （ちなみ、「HRアワード」という業界では有名なアワードで最優秀賞を取っている高性能なサービスだそうです…！！） 「自己理解」といえばストレングスファインダーなどが有名ですが、個人的にはコンピテンシーテストの方が圧倒的に満足度が高かったです…！！ ストレングスファインダーは世界中で有名で受験者数も多いんですが、だからこそ誰にでも当てはまる抽象的な結果しか出てきません…。 一方、コンピテンシー診断は転職サイト内のサービスとして開発されたテストなので、日本で働くビジネスパーソンがこれまでの仕事経験をもとに具体的に自己理解を進められる仕組みになっています！ そして、何より無料…！！！（ちな
プロダクトチームから成長につながる「決定的な一手」が出てこない。そんなことを感じてはいませんか。これはじつはプロダクトチームのユーザー理解が浅いときの典型的な症状です。「決定的な一手」は真に深いユーザー理解からしか生まれません。 プロダクトマネジメントにおいて、プロダクトマネージャー・プロダクトチームにUXリサーチのメンターがつくことで、強いチームへと成長することができます。
GraphQL Ruby 公式ページ RailsでGraphQLを扱う場合↑のgemを使ってAPIを実装していきます。 graphiql-rails 合わせて graphiql-rails gemを入れておくとブラウザ上で実装したGraphQLの 確認ができるIDEが使えるようになります :sparkles: ※ graphql-rubyのinstall時に graphiql-rails のgemをGemfileに追加してくれます イメージ画像 環境構築 $ rails generate graphql:install create app/graphql/types create app/graphql/types/.keep create app/graphql/app_schema.rb create app/graphql/types/base_object.rb create a
Vue.jsでCSSを利用する際にScoped CSSやCSS Modules、CSS-in-JSなどの手法があります。とくにScoped CSSは気軽に利用できるため、利用する機会も多くなって来るかと思います。 Scoped CSSがあればCSS設計を使わなくてもよいという意見もありますがはたして本当なのでしょうか？ ICSではScoped CSSにおけるCSS設計に関する議論が活発におこなわれており、本記事では私たちが考えた方式を紹介します。本記事はVue.jsのSFC（シングル・ファイル・コンポーネント）でScoped CSSを利用しているものを想定しています。 CSS設計とは 基本的にCSSは常にすべてのページで読み込まれ、増えれば増えるほど相互に上書きし合う状態が起きやすく、他の言語に比べてかなり壊れやすい言語と言えます。 そこで登場するのがCSS設計です。BEMやSMACSS、
requestAnimationFrame()というとCanvas APIなどを使ったクリエイティブコーディングでよく使われる手法ですが、クリエイティブコーディングに限ったものではなく、一般的なウェブサイトのアニメーション表現にも役立ちます。 この記事では「トップに戻るアニメーション」を例に、requesetAnimationFrame()の基本的な使い方から、実際のWebサイトで使える実装までチュートリアル形式で解説しています。 この記事で学べること requestAnimationFrame()でアニメーションするやり方 ディスプレイのリフレッシュレートに依存しない実装方法 イージング関数を使ったアニメーション さまざまな作例のサンプルファイルも用意しています。ぜひご覧ください。 サンプルを別ウインドウで再生する setInterval()との違い requestAnimationFr
はじめに CSSアニメーション以外でのtransform-originの使い方ありますか？ transform-originと戯れたので今回はこのローディングアニメーションの解説を行います。 完成品 ソースコード <!DOCTYPE html> <html lang="ja"> <head> <meta name="robots" content="noindex"> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>ee</title> <style> *, *::before, *::after { margin: 0; padding: 0; box-sizing: border-box; } body { background: #
こんにちは。Komercoの高橋です。 Komercoがリリースされてからもうすぐ3年が経とうとしています。 クックパッドの新規事業「Komerco」ではバックエンドのほぼ全てをFirebaseで運用してします。 新規事業のためエンジニアの数はまだ少ないものの、Firebaseのおかげでエンジニアはサービス開発に専念できている状況で、昨年はWeb版のリリースや送料無料イベントもあり、ユーザ数がさらに増加してきています。 これまで多くの機能を開発してきましたが、その中でFirebaseをより有効に使えるよう試行錯誤してきました。 これからFirebaseを使おうか考えている人にも、今現在Firebaseを使っている人にも参考になるよう、Komercoで得た知見を書いていこうと思います。 前後編となっており、前半はFirestoreの設計についてお話しようと思います。 当たり前の機能だけどFi
こんにちは。Figma プラグインを愛し、Figma プラグインに愛された男、そう、我こそは seya と申します。 先日 Figma から React のコードを生成するプラグインを公開しました。 そして、これのソースコードをこちらのレポジトリにて公開しています。 面白いと思ったらぜひ Star お願いします！⭐️ 上記レポジトリは React を生成するためのものですが、React 以外にも色々な形で View を書いているところがあるでしょう。なのでこの記事では、上記レポジトリのコードを拡張・編集して「自分だけの Figma コード生成機」を作れるための解説を書きます。 ちなみにですが、 Fork して作っていただいたものでもご自由に Figma Community に publish などいただいて大丈夫です。何か文句を言うことは一切ありません。ただ「作ったよー」とご報告いただける
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
