Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *
RubyKaigi 2023 Wi-Fi: 足回り徹底解説 - クックパッド開発者ブログ
id:sora_h です。最近は RubyKaigi の Organizer や Wi-Fi NOC をやっていましたが… 何屋なんだろう? 一応 Software Engineer (Site Reliability, Corporate Engineering) を名乗っていますが…。あっ RubyKaigi から戻ってからは学者をやってますね。落ち着いたら本業を思い出していこうと思います。 さて、Cookpad は 2010 年より RubyKaigi に協賛していますが、近年は Wi-Fi Sponsor など*1として携わっています。実体的には、 id:sora_h (筆者) が RubyKaigi 前にほぼフルタイムで Wi-Fi の準備に提供されたり、細々とした機材、一部の回線・ラックスペースの提供を行っています *2。 本稿では RubyKaigi 2023 Wi-Fi ネ
デバッグが早い人と遅い人の違い
会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作（バグ）はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの？」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を
分散型SNS「Misskey」、それを支える技術スタック | gihyo.jp
本連載は分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っていきます。第1回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 はじめまして！ はじめまして、Misskey（みすきー）のプロジェクトリーダーをしている、しゅいろ（@syuilo）です！ この度連載の機会をいただきましたので、ちょっと仰々しい気もしますが「Misskey & Webテクノロジー最前線」と題して、今後Misskeyやそれに関わる最新のWeb技術について解説をしていく予定です。 今回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 対象読者は、後半の実装解説の部分においてはある程度のWeb開発の知識がある人を想定しています。 Misskeyとは、そして分散型とは Misskeyは、オープン
アクセシビリティを普段の開発に定着させるためにやったこと #STORESアドカレ - STORES Product Blog
STORES Advent Calendar 2022 の 24日目の記事です。 こんにちは。業務委託で STORES の開発をしている @inouetakuya です。 昨年のアドベントカレンダーでも アクセシビリティについての記事 を投稿し、そのなかで、 hey もアクセシビリティの取り組みはまだ始まったばかりで、目標としている「普段の開発に定着させる」というところまでの道のりは遠いですが、2022年も前に進めていく所存です。 と書きました。 今回は続編として、今年 2022年に、アクセシビリティを普段の開発に定着させるために行った取り組みを紹介します。 2021年のおさらい - 学習と実践 2022年のスタート地点がどのような感じだったかをお伝えするために、2021年の取り組みにも触れておきます。 2021年は STORES にとってアクセシビリティ元年とも呼べる年で、アクセシビリテ
iPhone, iPadの最新機種まですべてを網羅、Appleデバイスのスクリーンサイズ・解像度のまとめ -Screen Sizes
Webサイト制作者・スマホアプリ開発者向けに、iPhone, iPad, Apple WatchなどのAppleデバイスのスクリーンサイズ、各サイズを採用しているモデル、ノッチのサイズ、解像度、PPI、表示タイプ、比率、セーフエリア、ウィジェットのサイズなど、実装時に役立つ情報がまとめられたScreen Sizesを紹介します。 2022年の最新モデル、iPhone 14シリーズ、iPad Air(5th Gen), Apple Watch Series 8をはじめ、最新機種から初代までの情報が網羅されています。 Screen Sizes サイトを利用するのは簡単、登録など面倒なことは一切不要です。 アクセスして、サイドバーから欲しい情報にアクセスするだけです。 iPhone 14 Pro Maxは今までになかった新しい解像度ですね。
高齢者向けサービスにおけるUIデザイン｜『高齢者のためのユーザインタフェースデザイン』の書評
現在、本業・副業ともにWEBデザイナーとしてデザイン・コーディングをしているゆるけーです。 本業で携わっているWEBサービスが割と高齢者向けのサービスで、ITリテラシーやUIが今の自分と考え方が異なるよなーと思っているなか、『高齢者のためのユーザインタフェースデザイン』という書籍に出会いました。 高齢者関係なく普通にアクセシビリティの観点でも重要な視点がたくさんあり、とてもいい書籍だったので、ざっくり大事だと思った箇所を抜粋しつつ自分で探した事例等をざっと記事にまとめていきますー。 視覚 高齢者になると視力が低下する傾向があります。ただ、視力の低下＝フォントを大きくするだけではありません。 視力の低下は老眼や光覚の減少などより複雑です。 主な視力の低下の具体例は以下のような点。 老眼：近く・遠くのものの焦点が合わない 周辺視野のぼやけ：画面の端に気づきにくい 中心視野の損失：画面の中央が暗
要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita
はじめに タイトルの主張が少し強いですが、以下の本を読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元の本では具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか？」 明確化 曖昧な表現を明確にする 例：「うまくできない」→「納期に間に合わない」 論理性チェック A
ユーザーのITリテラシーに配慮するのはアクセシビリティなのか - Qiita
主に2つの答えがあります。 A. WCAGの考えではユーザーが適切な支援技術を利用することも含めてアクセシビリティであり、支援技術の入手やアクセシビリティ機能の利用に必要なITリテラシーを持たない人はアクセシビリティの対象ではない。（WCAG偏重派） B. うるせえ！！ なるべく多様な人に情報を届ける、それがおもてなしの心ってヤツだろうが！！（アクセシビリティはみんなの心にあるよ派） 筆者には、Aのようにアクセシビリティの範疇からITリテラシーを外すのはやや極端な考え方であるように思えます。しかし、アクセシビリティに詳しい方でもAのような考え方をしているのを見かけます。 この記事では、WCAGやその関連文書を読みながら、この問いについて考察していきます。 今回WCAGとして参照するのはWeb Content Accessibility Guidelines (WCAG) 2.1です。この記
縦書きHTMLにおける文字の向きはどのように定まるか - ドワンゴ教育サービス開発者ブログ
ドワンゴ教育事業Webフロントエンドチームの berlysia です*1。 はじめに この記事では、日本語の縦書きHTMLにおいて、「ある1文字が縦組みのなかで違和感なく縦書きとして表示される」とはどのように成り立っているのか、意図しない表記になりやすい文字とその理由について紹介します。 最後まで読むと、縦書き時の文字の縦横に関する問題をたちどころに分解できるようになるはずです。とりあえずフォントのせいだろうかと疑う日々には、これでおさらばしましょう*2。 はじめに N予備校における日本語縦書きHTML CSS の関連仕様 日本語の一般的な縦書きに設定する うまくいかないことが起こりやすい文字たち うまくいかない文字がうまくいかない理由を理解する 縦書きを考慮した文字の周りの方向の定義 CSS における縦書きでの文字の縦横 upright typesetting sideways type
ヘルプページ作成タスクの透明性を上げたら、UXライターの経験知を共有知に昇華できた話 - SmartHR Tech Blog
こんにちは、UXライターの8chariです。早いものでSmartHRに入社して1年が経ちました！初めてTech Blogを書くのでドキドキしています。 SmartHRでは、フィーチャーチームでプロダクトを開発しており、開発プロセスの改善を日々行なっています。 この記事では、私が所属しているBチーム*1でヘルプページ作成のプロセスを見直し、チームのボトルネックを解消しようとしている話を紹介します。 特定の業務を担当できるメンバーが限られていて、以下のような課題を感じている方の参考になると嬉しいです。 必要なノウハウや知見がほかのメンバーに広まらない プロジェクトのボトルネックになっている 担当できるメンバーの負荷が高くなっている 前提 UXライターがいる開発現場はあまり多くないと思いますので、前提を説明します。 SmartHRのUXライターは「言葉の力でプロダクトを、もっとわかりやすく」する
CSSの単位px、em、remはどれをどこで使用するのがよいか、ピクセルとアクセシビリティにおける意外な真相
CSSの単位px、em、remは、どれをどこで使用するのがよいか。 font-sizeの値にはどの単位を使用していますか？ ほかにもメディアクエリを定義する時、マージンを定義する時、widthやheightを定義する時、使用する単位はアクセシビリティに配慮する必要があります。 The Surprising Truth About Pixels and Accessibility by Josh W. Comeau 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに CSSでpxとemとemの各単位がどのように機能するか アクセシビリティに関する考慮事項 どの単位をどこで使用すればよいのか どの単位がベストなのかが明らかでない場合 簡単にできる小技とメンタルモデル ボーナス: remを使用すると便利なテクニック はじめに C
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
AmazonSNSを使ったpush通知の実装について - Qiita
iOSアプリ開発で、AmazonSNSを使ってpush通知を実装したことについて書きます。 バックエンドはRailsで、フロントはSwiftです。 主に、バックエンドでpush通知を送付する機構を構築し、アプリ側ではそれを受け取ることだけをやってもらうような構成で実装したので、主にバックエンド側でのお話になります。 構成図 最初に作った機構の全体像を載せておきます。 push通知とは？ 言葉の定義（前提）を確認しておいた方がいいので、あえて書きます。 push通知を設計していて、自分が一番よく混乱したのが、push通知とお知らせ通知の概念を混同していたことでした。 基本的にpush通知はアプリのフォアグラウンドで受け取るため、push通知で来たメッセージを見た後は、その通知の内容の履歴を永続化しておくことはできません。 アプリ側のキャッシュ領域のようなところで持たせて保存しておく方法もある
エッセンスで学ぶwebアクセシビリティ - Qiita
この記事について こんにちは！この記事では、私が現在勉強中のwebアクセシビリティについてまとめていきます。 調べてみると、本格的にwebアクセシビリティへの配慮が行き届いていることに自信を持つには、w3c勧告のWeb Content Accessibility Guidelines2.1(WCAG2.1)で定められているAAA、AA、Aというランクを目指して指定されたチェックリストを満たすという方法があるんだな〜、WCAG2.1自体を読んで実施するのは疲れるからより噛み砕かれたfreeeさんのチェックリストを使ったりするんだな〜、ということが分かったりします。 しかし、freeeさんのチェックリストでも140ある項目を案件ごとに確認し直すのは大変だと思います。この記事では、そういった本気のアクセシビリティ施策をしないまでも、普段から気をつけられるアクセシビリティをご紹介します。 この記事
ChakraUI Buttonコンポーネントのレスポンシブ対応 - Qiita
ChakraUIのButtonコンポーネントについて Buttonコンポーネントのsizepropsはオブジェクトの値を入れられず、単一のstring（"lg" | "md" | "sm" | "xs"）しか入れることができません。 レスポンシブ対応をするときには現在のブレークポイントを返すchakraUIのhook useBreakpointValueを使うことで実現できます。 レスポンシブ対応を含めたコンポーネントを作成します import React, { forwardRef } from 'react' import { Button as ChakraButton, ButtonProps as ChakraButtonProps, useBreakpointValue } from '@chakra-ui/react' export type ButtonProps = {
【CDK】Cost Anomaly DetectionがChatbotと統合されたのでCDKで実装してみた【アップデート】 - Qiita
【CDK】Cost Anomaly DetectionがChatbotと統合されたのでCDKで実装してみた【アップデート】AWSSlackChatOpsCostExplorerCDK 背景 最近円安が進んでますね。 AWSの請求レートが上昇して心穏やかじゃない日々を過ごしています、という方に読んで欲しい 改めて確認したいAWSの予算設定 ついでに導入しておきたいCost Anomaly Detection(コスト異常検出) そんなCost Anomaly Detectionですが、3/14に以下のアップデートが発表されてSlackで通知を受け取ることが出来るようになりました！ 折角なのでCDKで実装して動作を確認してみました。 ※ついでにBudgetのslack通知も 本日より、AWSチャットボットを介してSlackとAmazonChimeでAWSコスト異常検出アラート通知を受信できるよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンド開発のためのセキュリティ入門
企業技術ブログ: エンジニアの技術ブログコミュニティ
https://www.fujitsu.com/downloads/JP/about/businesspolicy/tech/design/article/document/transformationbydesign-jp.pdf