TL;DR まあぜんぜん最強ではないですが、自分好みの配色 Web サービスをつくってみました yum-yum COLOR 個人で公開まで作りきったのは初めてでしたので、色々とつまずきました そんなつまずきポイントや、 Web サービスを公開するために利用した技術などを紹介していきます ❗ なぜ配色サービス ❓ 色彩検定という資格をご存知でしょうか? 僕はプログラマーなのに 色が好き で、この試験を受検しました。 その学習をしてる時にこんな風に思ったのです。 この色相環、これを使って配色選べたら便利じゃない? あっ、このトーン、これを使って配色選べたら便利じゃない?? と。 受検勉強の追い込みをしないといけないのに、そっちのけで作り始めてしまった...というわけです (一時はどうなるかと思いましたが、無事に検定は合格しましたよ 🎉 ) どんなサービスなの ❓ 使い方 色相環 と Hue
この記事はeureka Advent Calendar 2018 18日目の記事です。 そろそろ2018年も終わりかけですが、皆さんいかがお過ごしでしょうか。Webチームの竹内(a.k.a. BOXP)です。 もう今年も終わりということで、この記事では我々Webチームが今年新たに導入していったJavaScriptのライブラリを紹介がてら振り返りたいと思います。 目次1. normalizr2. reselect3. redux-thunk4. webpack-bundle-analyzer5. jest6. renovate最後に1. normalizrnormalizr はReduxやFluxのStoreに格納するデータの正規化を行うライブラリです。 抽象的な言い方をしましたが要するに同じIDを持つオブジェクトを簡単に共通化出来るもので、例えば以下のようにオブジェクトを正規化します Be
国内企業の28%がDevOpsを実践、うち41%が売り上げや顧客満足度向上などの成果を出していると。IDC Japan 調査会社のIDC Japanは、国内企業におけるDevOpsに関する調査結果を発表しました。対象となったのはDevOpsについて理解している国内企業のIT管理者で、有効回答数は515社。 「IT組織全体で実践している」という企業は12.6%、「一部の部門/プロジェクトで実践している」は15.5%となり、合計で企業のDevOps実践率は28.1%となりました。 IDCではDevOpsについて、「企業や組織がビジネスのスピード、品質、競争力などのケイパビリティを高めることを目標とし、複数のチームや担当者が共同でアプリケーションの開発から運用までのライフサイクルを効率化するための方法を取り入れ、それを実践すること」と定義しています。 DevOpsの実践で40%以上が売り上げなど
07 Jan 2019 mkcert: valid HTTPS certificates for localhost (or for any other name) The web is moving to HTTPS, preventing network attackers from observing or injecting page contents. But HTTPS needs TLS certificates, and while deployment is increasingly a solved issue thanks to the ACME protocol and Let's Encrypt, development still mostly ends up happening over HTTP because no one can get an unive
(この湖は軸がぶれてない。素敵。) 2019年に入ってから一週間くらい経つけど去年の思い出話を書く。 去年の後半はAnnictに対して表立った改修がほとんどできなかった。下の画像は2019年1月6日現在のお知らせ一覧だけど、6月に更新を行ってから12月末になるまで更新が途絶えている。(7月のお知らせは機能停止のお知らせなのでノーカンとしている) github.com/annict/annict も6月くらいから低迷している。 6月くらいから何をしていたかと言うと、Annictのシステムを一新する作業を始めていた。今思えば「V3作り始めます宣言」をDiscordに投下してから軸がぶれ始めたと思う…。 (AnnictのDiscordサーバはこちらです: https://discord.gg/PVJRUKP) 当初は下記のような構想を考えていた。 Railsで作られている現行システムをElixi
この記事について 「Willgate Advent Calendar 2018」11 日目の記事です。 記事が投稿された日付は気にしてはいけない。いいね? きっかけ およそ 2 ヶ月前に下書きになっていた記事があったので掘り返し。 この記事を書き始めたころの twitter のタイムラインにこんなツイートが流れてきました。 エンバグを断罪するような思考そもそも気に入らない。個人の注意力に依存するのは工学的じゃない。罪はバグが発生しやすい設計にあると考えるのがエンジニアじゃないの? って思う。個々のバグに対して迷惑被ったと怒るのはエンドユーザー視点しかない人だと思う— 田中ひさてる (@tanakahisateru) 2018年10月2日 私もこれに近い考えをずっと抱いてきていたので、引用リツイート + コメントせずにはいられませんでした。 本当にこれ。 バグらないように「気をつけて」作るん
インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い
この記事はCrowdWorks Advent Calendar 2018 の2日目の記事です。 はじめに こんにちは。 クラウドワークスでプロダクトオーナーをしている 柴田 @shiba_319 です。 私の担当するWEB開発チームでは、今年6月から10月の約5ヶ月間、クラウドワークスのコア機能の一つである「仕事依頼画面」の大規模なリファクタリングプロジェクトを行なっていました。 私は、普段コードを触るのはちょっとしたスタイル修正や簡単なコード修正程度の非エンジニアPOなのですが、 今日はそんな自分が 「約6万行の大規模リファクタリングを完遂するうえでPOとしてやってよかったこと」を書きたいと思います。 4名の開発チームで大規模リファクタリングをすることになった経緯 私たちの開発チームは、当時4名チームで、クラウドワークス発注者向けのUI/UX改善を担当していました。 (構成はエンジニア2
こんにちは、koidです。こちらは Gunosy Advent Calendar 2018 、25日目の記事です。昨日の記事は @hoshitocat さんの Swaggerでインタフェースの共有をしつつ社内管理画面を作る でした。 早いもので、Advent Calendarもあっという間に最終回となりました。この記事を持って、今年も無事(?)完走となります。 さて、本題です。 今年も弊社では、様々な技術*1や手法にトライし、プロダクションへの導入を行ってきました。 そんな中で、そういった新しい技術を導入していくにあたり、どんなことを大切に考えているのか、先日 IVS CTO Night というイベントでLTをする機会があったので、その際にお話ししたことを書きたいと思います。 技術は目的ではなく、課題解決のための手段である どんな課題を解決したいのかを明確にする 良くない例(課題が明確にな
この記事はRecruit Engineers Advent Calendar 2018 - 13日目の記事です。 追記 本記事の内容にて、s-dev taksで登壇してきました speakerdeck.com 前書き 本記事は個人的な見解を示したものであり、所属する組織を代表するものではありません。内容には留意しておりますが、もし不適切な内容や誤りがあれば、私個人当てにご指摘のコメントをいただけますと幸いです。 超概要 カットオーバーから数年経ったtoCサービスにおいて、エンジニアオンリーのチームで企画・開発・分析、プロダクト改善のサイクル全てを担うチームの立ち上げを行いました 開発しか知らない僕らがよりよい価値を世に届けるために、企画や分析方面への染み出しを行う中での泥臭い取り組みや、やってみて分かった知見を共有します 経験ベースで築いてきた知見なので、理論を踏まえてなかったり、原理原則
This is an introduction to modern web loading performance. Learn why performance is important, what performance optimizations exist, and which tools can help you understand if your app is performing well. Want to apply this advice to your site? We help companies like Framer, Toggl, SitePoint to get faster – and we’d be happy to help you as well! Reach out So: why is web performance important? Firs
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの?という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元: テクニックではなく、今、本気で取り組むべきWebパフォーマンス (html5jパフォーマンス部 部長 竹洞さん) 心得 パフォーマンス向上に対する施策は大別すると以下の2通り 軽量化 (単純にやりとりするデータ容量を小さくすること) 圧縮 削除 最適化 (その時に最も適している実装・実行をとること) 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
はじめに とある企業で組み込み系ソフトエンジニアとして働いていますが「このままだと、将来ないかも?」と思えてくる場面に日々遭遇します。 今回は日本の組み込み業界の将来が不安になる、耳を疑った”上司の発言”をまとめてみました。 「最近の若いやつらは残業が足りない」 働き方改革が騒がれるこの時代に、そんなこと言う人いるの!? と驚く方もいるかもしれないですが、いるんです。 そして、それがまかり通る現場の一番の問題は 「開発業務の効率化、スピードUPを図る文化が根付かない」ことだと私は思っています。 「時間が足りなければ残業でカバーすればOK!残業代も出るし、いいでしょ。」 という考え方では、どうすれば開発スピードが上がるか?無駄な作業はないか?自動化できることはないか?といった改善のアイデアは、なかなか出てきません。 残業を推進し次から次へと業務が積まれていくような現場では、改善のアクションの
サマリ 正社員0で業務委託のみの10人程度の小さな開発チームは結構安定していい感じに運営できるみたい。 チームが小さい間は現実的な選択肢としてありえる。 前置き これから、僕がCTOをやっているAIトラベルという会社で、うまいことエンジニアチームを回せるようになってきたぜ!みたいなことを書くのですが、決して僕個人のエンジニアのキャリアの中でエンジニア組織をうまく回せてきたわけではありません。 いくつかの開発組織を経験して、直接僕が原因であったわけではない(と信じたい)ですが、開発チームがうまく機能しておらず、どんどん人が減っていく状態をエンジニアの立場から見てきました。そして自分に力がなく、それを改善することは出来なかった苦い思い出もあります。 そういう悲しい経験も踏まえて、エンジニアチームをどう運営していけば、小さいチームでも着実にプロダクトを育てていけるのかをいろいろ考えてきたので、少
本連載では、株式会社ビズリーチのエンジニアが、急成長を続ける事業の中で得られた実践的なノウハウをつづります。第3回となる今回は、6月に始めたエンジニアブログ「BizReach Tech Blog」で反響が大きかった記事を加筆修正して掲載します。テーマは「AWSネットワーク構成図の手動更新がつらい? よろしい、ならばCloudMapperだ」です。CloudMapperの紹介と、全自動でネットワーク構成図を作成するための方法をご紹介します。 BizReach Tech Blog はじめに 株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOS(ハーモス)採用管理というサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。 今回は、入社してから半年経ったら、いつのまにかサービスのネットワーク管理者になってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く