#Gunosy Tech Blog

[tak4hir0]

こんにちは！スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です。 弊社ではプロキシにenvoyを利用するのが一般的になってきました。 これはenvoyを使うことでトラフィックのメトリクスを可視化しやすくなるからです。 envoyを利用するとredisなどの通信も挟むことができますが、envoyのroutingコントロールを手で運用する（手でyamlを書く）のがつらすぎるので、 本サービスではAPIのHTTPエンドポイントの��クエストレスポンスのみにenvoy を適用しています。 また、APIから参照するデータストアはRedisだけになっており、 local cacheとsingleflightを組み合わせて負荷を下げることで安定的にデータを参照できています。 オートスケール 以前spotインスタンスでECSを構成したものを記事で紹介しましたが、今回もfrontのAPIはspotインスタンスで構成しています。 tech.gunosy.io オートスケールには、一般的なcluster autoscaler とHorizontal Pod Autoscalerを使っています。 また、spot運用のため、node termination handlerによる通知でgracefulに停止するようにしています。 cluster autoscalerはpodがpendingになってからスケールするという性質上スケールが遅いので、CPUのターゲットしきい値は60%にすることでトラフィックの急増に耐えています。 また、リクエストの波がピーク時と閑散期で3倍ほどあるので、1pod増えた際のスケール幅を増やすため、インスタンス一台に対してpodが5台くらいになるようにpodサイズを指定しています。 また以下がdeploymentのyamlサンプルです。 kind: Deployment spec: replicas: 1 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 template: spec: containers: - name: front-api volumeMounts: - mountPath: /tmp name: cache-volume readinessProbe: httpGet: path: /ping port: 8081 lifecycle: preStop: exec: command: ["sh", "-c", "sleep 15"] - name: fluent volumeMounts: - mountPath: /tmp name: cache-volume lifecycle: preStop: exec: command: ["/bin/sh", "-c", "while wget -q --spider http://127.0.0.1:8081/ping; do sleep 1; done"] - name: envoy command: ["envoy", "-c", "/etc/envoy/envoy.yaml"] volumeMounts: - mountPath: /etc/envoy name: envoy-config-volume readOnly: true readinessProbe: httpGet: path: /ping port: 8080 lifecycle: preStop: exec: command: ["/bin/sh", "-c", "curl -s -XPOST 127.0.0.1:9901/healthcheck/fail; sleep 10"] volumes: - name: cache-volume emptyDir: {} - name: envoy-config-volume configMap: name: envoy-config 弊社ではenvoyを利用していますが、特にプロキシを挟む用途がなければenvoyのコンテナを使わなくても問題ありません。 ログ処理 ログの転送にはfluentdを利用しており、アプリケーションのpodにはfluentdのサイドカーを利用し、そのログを別のfluent aggregatorのstatefulsetに転送しています。 statefulsetはonDemandを利用しています。 理由としてはaggregatorが頻繁に生き死にすることでログの欠損の可能性が増えることを避けたいのと、 AWSのEBSが同一AZのインスタンスにしかつかず、spotのインスタンスの偏りが発生した際にEBSが紐付かなくなり立ち上がらないなどのケアのためです。 アプリケーションのpodでは、ステートレスにするためflush buffer timeを1秒にしてaggregatorに流しています。 また、上のyamlで記���しているようにappのコンテナより先に死なないようにpreStopでapiの死活を監視し、appコンテナが死んでからfluentのコンテナが落ちるようになっています。 appとfluentコンテナのログの受け渡しはemptyDirを介し��渡しています。 aggregatorはbufferをある程度貯めるのでログの欠損をさせないようにstatefulsetにしています。 またトラフィックが多いので、コスト削減のためリクエスト数に応じてシャードによる課金額が増えるKinesis+lambdaでRedisに投入するのではなくfluent pluginを作成して直接Redisに書き込みを行っています。 この変更によってk8sクラスタ内で処理が完結するので、ローカルでのテストが実施しやすくなりました。 また、一部の必須ではないログはアプリケーション側で間引くことでログのS3費と転送料を減らしてコスト削減しています。 各リソースの関係 CI CIには現在skaffoldを使っておりimageの作成からkubectl applyまでをskaffoldが担ってくれています。 弊社ではCI-imageを各種作っているので、CircleCIのdeployの設定でも以下だけでdeployできるようになっています。 gunosyのpublic repositoryで作成しているので参考にしていただければと思います。 Gunosy · GitHub docker: - image: gunosy/ci-skaffold:1.0.1 steps: - checkout - setup_remote_docker - run: name: docker login command: $(aws ecr get-login --no-include-email) - run:-cluster - run: --label skaffold.dev/run-id="static",skaffold.dev/docker-api-version="static",app.kubernetes.io/managed-by="skaffold",skaffold.dev/tag-policy="static" 現在はskaffoldを利用していますが、canary deployなどを実行する際は、Argo Rolloutsやサービスメッシュなどを導入する必要があります。 が、初手はこれで十分かと思います。 また、kube-systemなどクラスタ全体に関わる設定はterraformで管理し、各アプリ周辺のyamlやDockerfileはアプリのレポジトリで管理しています。 kube-system ALBを利用しているので alb-ingress-controller を利用しています。 また監視にはdatadogを使っているので、datadog-agent をdaemonsetとして稼働させています。 詰まると言われるDNS周りですが、CoreDNS のHPA運用にしており今のところ特に問題なく稼働しています。 現在広告チームのEKSの同一クラスタに3サービス稼働しており、うち2サービスは秒間1万リクエストを越えています。 それらのリソースが食い合わないように各サービスごとにASGは分けており、 自分たちが管理するデータプレインをそれぞれ分けることで独立性を保っています。 まとめ 以上の構成で5xxはほぼ発生しない安定運用が実現できています。 せっかく書いたのですが、意外に普通の構成のことしか書いていませんでした。 逆に普通の構成でもかなりのリクエストをさばけるということをお伝え��ることができたかと思います。 k8s導入の参考になれば幸いです。

[kennak]

貧乏プロジェクトでDBバックアップをgz圧縮+分割してGmailのゴミ箱へ投げてた

[B! aws] S3のコストを大幅に削減した話 - Gunosy Tech Blog

[kjunichi]

Gunosy広告技術部を支えるKPI用語集 - Gunosy Tech Blog [はてなブックマーク]

Gunosy広告技術部を支えるKPI用語集 - Gunosy Tech Blog

2018 - 05 - 30 Gunosy広告技術部を支えるKPI用語集 広告 はじめに こんにちは、広告技術部アルバイトの徐（ @joha__rb ）です。普段の業務では、広告配信の管理画面システムの開発をしております。 さて、皆さん普段お仕事をされる上で「KPI」という単語を使われたことはありますか？　KPIとは Key Performance Indicator の略語であり、日本語訳すると...

kjw_junichi あとで読む

from kjw_junichiのブックマーク https://ift.tt/2JjDhxP

[dothtml5]

エンジニア白書2020 - Qiita利用ユーザー約3,000名を対象に大規模アンケート調査を実施 (Qiita)

ガートナー「先進テクノロジのハイプ・サイクル：2020年」を発表 - ソーシャルディスタンス技術、説明可能なAI、などが過度な期待 (Publickey)

UXをAIプロジェクトに導入する5つの方法 (TechCrunch)

デザインの教室をFigmaで写経してデザインの勉強をした (Web Scratch)

2020年が日本のデザイナー達に与える12のインパクト (freshtrax)

Screenshot.Rocks - スクリーンショットを使ってウェブブラウザのモックアップを作成 (MOONGIFT)

今すぐ始められるOSS活動 (Gunosy Tech Blog)

情報過多時代に必要な知識の整理を始めよう (could)

思いやりのあるオフボーディング (社員が離職するときのサポート) を考える (UX MILK)

[globalmediacampaign]

How Gunosy built a comment feature in News Pass using Amazon Neptune

This guest post is a translation and adaption from How to implement and operate News Pass comment feature in GraphDB using Amazon Neptune, published in Japanese by Gunosy. Gunosy’s motto is to “Optimally deliver information to people around the world.” In their own words “Gunosy has developed and operated multiple media businesses, including the information curation service Gunosy; the news distribution application News Pass, which is provided by Japanese telecommunication provider KDDI and Gunosy jointly; and the women’s trend information application LUCRA. In addition to the media business, Gunosy also has business in ad-tech, Gunosy Ads, and the Gunosy Ad Network. The information curation service collects and distributes information sourced from the vast amount of information on the internet, filtered by specific criteria. Gunosy uses algorithms to collect and organize information to deliver the right information to the right people.” News Pass is a free application that allows customers to check trending news easily. The application can deliver selected information from affiliated media automatically by using a unique information analysis and distribution technology. News Pass allows users to add their comments to a news article. This post discusses how Gunosy implements and operates the News Pass comment feature using Amazon Neptune. Why did Gunosy choose Amazon Neptune? Before we implemented the comment feature in News Pass, we considered an implementation using Amazon Aurora and Amazon DynamoDB. However, we decided to adopt Neptune because comments are primarily a graph structure. We liked that it is easy to add features, such as adding comments to an object (for example, another comment) other than the news article itself. Another advantage is that it is easy to implement simple recommendations. What does the graph in Amazon Neptune look like? Neptune enables comments for articles in News Pass. The following diagram shows the data structure of the comment data. The data structure includes the following elements: The edge of about connects the article and comment (A comment about an article is linked to that article.) The edge of post connects the comment and user (A user posts the comment.) The edge of like connects the comment and user (A user likes the comment.) The edge of delete connects the comment and user (A user who posted a comment can delete it.) The comment vertex holds id and body as properties. A vertex can have many properties, and an individual property can be held as an array. For like, post, and delete, each edge has the timestamp of when they were connected as a property. Unlike vertices, an edge can only have one single property. In this way, the graph database uses vertices and edges, as well as their labels and properties, to easily represent many kinds of objects and relationships between individual objects. We can also increase or decrease the number of properties on individual objects because we don’t have to define the strict schema beforehand in Neptune, unlike relational databases. For example, to implement a function to comment on a specific comment, you can extend a line from the comment vertex with about edge and complete the connection with the target comment vertex. Performance optimization With Neptune, we could achieve a response time of 40 milliseconds at the 99th percentile for the API to get comments. However, to maintain a fast response time, we needed to configure data structures and queries appropriately. The following is the explanation of the data structures and queries we optimized to maintain the fast response time in Neptune. Data structure For operational reasons, the operator had to regularly get comments that commenters had already deleted. Initially, the property of the comment vertex optionally held deleted_at, which indicates the data had been deleted in the data structure. The following diagram shows a sample of the deleted_at data. The following code is the Gremlin query: g.V().hasLabel(“comment”).has(“deleted_at”) However, this data structure slowed down the query while the amount of data increased. Therefore, without relying on properties, we tried to express the same query using vertices and edges. We added the delete edge to connect the comment and user vertices. The following diagram shows a sample of data after the changes. As a result, the speed to execute the query did not slow down, even with millions of comments and tens of GB of comments. The query now looks like the following code: g.E().hasLabel(“delete”).inV().hasLabel(“comment”) Gremlin queries Queries can have a significant impact on performance, depending on how you write them. For example, in News Pass, when extracting comment data from the CommentID, we originally used the following query: g.V().hasLabel(“comment”).hasId(“CommentID you search for”) However, the following modified query returns the result much faster: g.V(“CommentID to search for”).hasLabel(“comment”) The difference is whether you filter by label or ID of vertex first. Typically, in a relational database, it is faster to filter by ID first. The graph database acted in the same way. Summary In graph databases, you can use vertices and edges, as well as their labels and properties, to easily represent many kinds of objects and relationships between individual objects. The same functionality is difficult to achieve with relational databases. In our experience, we have seen that Neptune can deal with tens of thousands of comments a day while maintaining a fast response. In addition, it is easy to scale in and scale out with Neptune, and straightforward to operate. At Gunosy, we access our database using the in-house developed Go library, but there is a variety of Neptune’s official client libraries that support multiple GraphDB versions. Therefore, it is easy and simple for developers to build applications using Neptune.     https://aws.amazon.com/blogs/database/how-gunosy-built-a-comment-feature-in-news-pass-using-amazon-neptune/

[mersy]

こういうのやってみたいな >>> チームの継続的改善を支える制度: Kaizen Day - Gunosy Tech Blog https://t.co/nxT6s5JpaW

こういうのやってみたいな >>> チームの継続的改善を支える制度: Kaizen Day - Gunosy Tech Blog https://t.co/nxT6s5JpaW

— mersy@bit part & kototoy & i-Pairs (@mersy) October 16, 2018

from Twitter https://twitter.com/mersy October 16, 2018 at 10:08PM via IFTTT

[tak4hir0]

DXとかDevOpsとかのなんかいい感じのやつ　富士通TechLive 1. DXとかDevOpsとかの なんかいい感じのやつ 2020/03/03 富士通 Tech Live 中山ところてん 1 2. 自己紹介 • ところてん • @tokoroten • 株式会社NextInt 代表 • 怪文章職人・インターネット芸人 • 最近のお仕事とか • 謎の講演とかワークショップ業 • 機械学習顧問（2社） • モバイルミドルウェア企業 • データ分析企業 • 新規事業コンサルティング（1社） • 業務改善コンサルティング（1社） • ゲームディレクター(1社) ↓共著 ↓寄稿↓共著 2 3. 今日の経緯 • だいたい、緑の恐竜が悪い 3 4. 注意 • このスライドは緑の恐竜がだいたい悪い • 自分が勉強したことや見聞きしたことが適当にまとまってます • ポエムであり怪文章です • 本ポエムは「闇のDevOps」というブログ記事を下敷きにして います • https://medium.com/@tokoroten/5aff8b60f589 • だいたい緑の恐竜が悪い、いいね？ 4 5. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 5 6. Why Software Is Eating The World http://sora.rainbowapps.com/software https://www.wsj.com/articles/SB100014240531119034809045765122509156294606 7. ソフトウェアが全てを飲み込む • ソフトウェアによって置き換わったもの • 電話 → スマートフォン • カメラ → デジカメ → スマホ • レンタルビデオ → Youtube、NetFlix • 映画 → Pixer • 書店 → Kindle • タクシー → Uber • 地図 → Google Map • 小売店 → Amazon • 財布 → 電子決済アプリ • 全ての 8. President Obama asks America to learn computer science https://www.youtube.com/watch?v=6XvmhE1J9PY 8 9. • コンピュータ・サイエンスのスキルを身につけることは、皆さん自 身の未来のみならず、私達の国の未来にとっても、大事なことです。 • アメリカという���が最先端であり続けるためには、皆さんのような 若いアメリカ国民に、今後の世界のあり方を変えるようなツールや 技術について学んでもらわねばならないのです。 • 初めからコンピュータ・サイエンスの専門家の人なんていません。 しかし、少しの努力と数学と科学の知識で、誰でもコンピュータ・ サイエンティストになることができます。 • コンピュータは皆さんの未来の大部分を占めることになります。 President Obama asks America to learn computer science 9 10. 余談：オバマ前大統領のスピーチの背景 • 2013年12月に行われた、コンピュータ科学教育週間の応援 • コンピュータ科学教育週間の主催はCode.orgというNPO • https://hourofcode.com/jp • Hour of Codeというイベントを実施 • 1時間のプログラミングでコンピュータサイエンスに対する理解、興味 を持ってもらうのが目的 • 2013年はアメリカのみならず、170の国や地域から約1500万人が参加、 累計で５億行のプログラムが書かれた • コンピュータサイエンスを通じて「問題解決能力」「論理的思考」 「創造性」をはぐくむことで、21世紀のキャリアパスにおいて成功す る基盤を身につける 10 11. What Most Schools Don't Teach https://www.youtube.com/watch?v=nKIu9yen5nc 11 12. 全てはコンピュータに 12 13. 全ての職業にプログラマーが必要 • ポール・グレアム、Yahooに起きてしまったこと http://blog.livedoor.jp/lionfan/archives/52682119.html 13 14. 100の職業でどんな数学が使われるか • When Are We Ever Gonna Have to Use This? （1996） https://readingmonkey.blog.fc2.com/blog-entry-625.html 14 15. 100の職業でどんな数学が使われるか • コンピュータの利用は82/100の職業で必要 • プログラミングは13/100の職業で必要 • ただしこれは1996年の書籍 • 現在はもっと比率が上がっている と思われる https://readingmonkey.blog.fc2.com/blog-entry-625.html 15 16. 全ての産業でコンピュータが使われている • コンピュータ無しでの現代の産業は成り立たない • 1996年の書籍でも82/100の職業でコンピュータを使う • 日本の場合 • 工場の情報化は80年代から • 一般オフィスへの浸透は2000年ごろ • 1990年前後と現在を、フィクションの中で比較してみる • 1988 美味しんぼ • 1989 機動警察パトレイバー • 2015 SHIROBAKO • 2016 シン・ゴジラ • 2018 アグレッシブ烈子 16 17. 1988 美味しんぼ • 新聞社のオフィス • ワープロもなければパソコンもない 17 公開版は画像省略 18. 1989 機動警察パトレイバー ON TELEVISION • 当時はコンピュータは「電算室」にあるものだった 18 公開版は画像省略 19. 2015 SHIROBAKO • アニメの制作デスクはPC上で仕事をする 19 公開版は画像省略 20. 2016 シン・ゴジラ • 職員（国家公務員）はすべてPCを活用して仕事を行う 20 公開版は画像省略 21. 2018 アグレッシブ烈子 • 経理は全員PCを利用して仕事をしている 21 公開版は画像省略 22. 世界経済の変化（時価総額トップ10） https://finance-gfp.com/?p=2042 https://finance-gfp.com/?p=6595 石油、小売り、電気、通信、タバコ、銀行、薬品 ソフトウェア、ソフトウェア、銀行、医薬品 22 23. 日本経済の変化 https://finance-gfp.com/?p=2042 https://finance-gfp.com/?p=6595 23 24. 余談）石油王には勝てなかったよ…… • 2019年12月、サウジアラムコ（サウジ国営石油）がIPO • 時価総額200兆円超、世界一の時価総額に https://www.180.co.jp/world_etf_adr/adr/ranking.htm 24 25. 世界ではなにが起こっていたのか？ • DX、DevOps、toCのソフトウェア会社が躍進 • ソフトウェアを全世界に輸出できている • 日本企業はうーん… • ソフトウェアの輸出ができていない？ • じゃあ、DX、DevOpsって何よ？なんでDevOpsが必要なの？ 25 26. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 26 27. DevOpsの初出 • 2009年、Velocity2009 • Flickrの事例 • 「DevとOpsが協力することで、1 日に10回のデプロイが可能にな る」 • やっていること • インフラの自動化 • バージョンコントロール • ビルドとデプロイが1ステップ • 監視の自動化、IRCにログ • etc https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 27 28. 28 https://commons.wikimedia.org/wiki/File:Devops.svg 29. CPAである限り無限スケール • マーケットの変化速度の上昇 29 30. 収益の主体がOpsに • ビジネスがサブスクリプション化 • Netflix、YouTube Premium • Amazon Prime、Kindle Unlimited • 各種SaaSアプリケーション • コマツ、KOMTRAX • GE、航空機のエンジンのサブスクリプション • Opsがよければユーザは契約を続ける • ＝品質が高ければLTVは上昇する • 満足度が高い顧客は、新規顧客を連れてくる • 口コミで評判を広めてくれるので、広告が効きやすくなる • ＝品質が高ければCPAが大幅に下がる 30 31. CPAの世界 • 利益＝LTV-CPA • これが実現できていると、広告を打てば打つだけ利益が出る状態 • クラウドのスケールアウトと組み合わせて、急激な顧客拡大が可能になる • Opsが人手で事業拡大に時間とコストがかかるとこうはいかない 31 32. CPAの戦い方 • 例）IPO直前のGunosyは調達した資金をほぼ広告に投入 32 https://jp.techcrunch.com/2014/06/23/j p20140623gunosy/ https://jp.techcrunch.com/2014/0 3/14/jp140314gunosy-kddi/ 33. マーケットの変化速度の上昇 • 5000万ユーザ獲得までの時間 33 https://steemit.com/steemit/@johnnywingston/how-long-does-it-take-steemit-to-hit- 50-000-000-users--1502430927-1670258 34. 変化に対応するには細かい軌道修正が必要 • 従来の中央研究所方式の製品リリースでは世界と戦えない • 研究所で数年 • 事業会社でさらに１年開発 • 運用移管して数年の運用 • より短い期間で軌道修正を行える者が勝つ • リーン開発、スクラム、DevOps、DX 34 35. 生き残る種とは、最も強いものではない。 最も知的なものでもない。 それは、変化に最もよく適応したものである。 チャールズ・ダーウィン35 36. わが社でも DevOpsをやってみたいので、 どのツールを使えばいいのか 教えてほしい 36 37. 違う、そうじゃない 画像省略37 38. なぜDevOpsという言葉が出てきたのか？ • DevとOpsは組織が分かれており、対立していることが一般的 だった コードのせいじゃないよ マシンのせいでしょ?マシンのせーじゃねーよ コードのせいだろ！！ 38 39. なぜDevとOpsは対立していたのか？ • 部署が分かれている • 評価基準が違う • 採用が違っていた 39 40. 直交する評価基準 安定性 新機能 新しい機能を追加すると、 バグは必ず出る 40 41. 直交する評価基準：Dev目線 安定性 新機能 現実 新機能追加しました！！ これで儲かります！！ 41 42. 直交する評価基準：Ops目線 安定性 新機能 現実 新機能で儲かるわけねぇよ どうせまたバグが出るだけだろ 42 43. ベクトルで分かる、部門対立 • 評価軸が部門ごとに独立 • Devは新機能軸を評価する（評価される） • Opsは安定性軸を評価する（評価される） • どうしてこうなった？ • ハードウェアの時代の歴史的経緯による分業 • 現代では、分業による効率化、餅は餅屋 43 44. ハードウェアの時代の歴史的経緯 • 研究・開発・運用サポートの分離 • 少数精鋭・高学歴の研究開発 • 基礎技術の研究開発 • 製品の開発のための図面起こし • 高等教育を受けた製造オペレータ • 工場労働、製品の品質管理 • 大量の運用人員、労働集約産業 • 設備の設置、修理サポート、販売支援 • コールセンターサポート • 製品に何かあったら運用でカバーはこの時代から • ハードウェアはなかなか直せない 44 45. ソフトウェアの時代へ • ソフトウェアはハードウェアの従属物の時代 • ハードウェア時代のウォーターフォール開発が そのままソフトウェアに適用される • ハードウェア時代の組織構造がそのままソフトウェアに適用 • 設計：コードの設計をする人 • 製造：コードを書く人 • 保守：コードの運用＋マシンのメンテをする人、サポセン • ソフトウェアのリリースも一年に一回、半年に一回程度 • 運用でカバーで何とかなっていた 45 46. 企業のネットが星を被い 電子や光が駆け巡っても 国家や民族が消えてなくなるほど 情報化されていない近未来 攻殻機動隊 GHOST IN THE SHELL(1991)46 47. 時代はインターネットへ • 毎日が機能追加、毎日がデプロイ、毎日がバグ • 開発部門は機能開発・売上が業績評価指標 • 運用部門は稼働率、SLAが業績評価指標 • 開発と運用では必要なスキルセットが異なるので、分業する • 開発部門と運用部門の業績評価指標が直交 • DevとOpsが対立する • じゃあ、これを何とかしようぜ、というのがDevOps • そして、そのキッカケはクラウドの登場（だと思っている） 47 48. 余談）少しずつ壊れていく分業 • 最初はうまくいく • なぜ部門が分割されたか皆が知っている • 隣の部門をカバーするように動く • 評価制度が狂いはじめる • 問題を分割したことによって、 評価が分かりやすい数字に置き換えられる • 部門の数値目標が一人歩きを始める • 個人の評価も同様の数値目標で行われるようになる • 考える人が居なくなる • 与えられた評価基準を満たすように皆が動くようになる • 隣の部門の問題は誰も知らない • 部署の間に落ちたボールは誰も拾わなくなる 48 49. クラウドの登場 • 1999年 VMWare • x86の完全仮想化 • 2000年 FreeBSD jail • 1台のPC内のユーザを仮想的にアイソレーションする • 2003年 Xen • 2005年 OpenVZ • 2006年 AWS EC2 • APIでキックしてインスタンスを立ち上げる • 2009年 FlickrがDevOpsの講演 詳しい話は緑の恐竜に聞いてください49 50. 余談：クラウドと仮想化って何が違うの？ • 仮想化：基礎技術、1960年代からあった • 分散処理：基礎技術、1960年代からあった • クラウド：提供形態、2006年ごろから • クラウドは仮想化されたコンピューティング資源が、APIを経由してプログ ラマブルになったサービス • コンピュータを制御するのに、人の手を介さないでもよくなった • 人間が直接管理できるコンピュータはせいぜい10台程度 • コンピュータをコンピュータで制御することで限界突破 • より優れたプログラマは、より多くのコンピュータを扱える時代 • クラウドは人間の能力の限界を突破させた 50 詳しい話は緑の恐竜に聞いてください 51. 余談：Иττのクラウドに絶望した話 51 52. 余談：Иττのクラウドに絶望した話 • 入社式で分散処理の専門家のS先生がゲスト公演 • クラウドは人間をエンパワーする • より優れたプログラマが、 より多くのコンピュータを扱える時代が来る • クラウドとは人間の能力を100倍、1000倍に引き上げる仕組み • 社長の講演は全く覚えてなかったけど、 S先生の話は自分に深く刻まれていた • Иττのクラウドは人間をエンパワーしているか？ • していない → 退職へ 52 53. クラウドの登場で何が変わったのか？ • クラウドにより「計算機資源そのものが仮想化され、計算機資 源がプログラマブルになった」 • Ops業務のメインは「サーバ管理」＝「計算機資源のマネジメント」 がであったが���これの大部分がプログラマブルになった • 仮想化や自動化に対して様々なツール・サービスが登場 53 54. Opsの手作業業務の大部分が自動化 • サーバラックに機材を積み込んで、 電源入れてOSインストールして、 必要なパッチを当てて、 ネットワーク回りの設定を書き換え、 サービスをデプロイして、 ログを画面に表示して目視確認して…… • 開発初期におけるOpsの手作業業務の大半がプログラマブルに • Infrastructure as a Code、 Immutable Infrastructure、に繋がる • DevがOpsの業務を取り扱えるようになった • Opsがプログラミングによって自らの仕事を減らすのもアリだが、 日本ではプログラミングのできるOpsが少ないため、 結果的にこうなることが多い 54 55. CPA時の急拡大対応 • DevとOpsの業務をプログラミングにより垂直統合 • 「手を取り合えば効率的になる」というわけではない • Opsの仕事をDevがプログラミングで奪い取る • 業績評価指標の見直し • 分業から垂直統合仕様に • 垂直統合前提で業績評価指標を見直す 55 56. DevOpsとはツールではない • 業務プロセスの垂直統合 • プログラマーの活動範囲の拡大 • オペレーションまで加味した全体最適化 • 全体最適化なので、業績評価指標を「全体最適」にする必要 • 個別最適の業績評価指標のままではDevOpsはできない 56 57. 業績評価指標をDevOps仕様にする • 一番簡単なのは生株付与やSO • 会社の評価額の上昇が、自らの利益になる • サービスの価値が上がる、会社の評価額が上がることなら何でもやる • 次に簡単なのはサービスの利益連動ボーナス • とはいえ、サービスの利益を計算するのはとても大変 • 人数が多くなると、その人の貢献を計測するのは超大変 • 配属ガチャで給与が決定されるという問題が生まれる • GoogleではSREとプロダクト開発チームはError Budgetを共 通の指標にする 57 58. Error Budget • SLO(Service Level objectives)に基づくError Budgetを設定 • DevとSREは Error Budget を共通の評価指標に • Devも稼働率を改善するのに協力する • サービスがダウンすると、その分 Error Budget が削られる • Error Budget が尽きるとデプロイできなくなる • Error Budget が尽きそうになったら、デプロイの間隔を下げる • その分、コードレビューやテストを厚くする • サービスの種類によって、設定されるBudgetの 大きさは異なる • 安定性が重要なtoBサービスは小さく • 改善速度が重要なtoCサービスは大きく • プロダクト性質に応じて柔軟に変更する 58 59. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 59 60. 日本の労働法の歴史的経緯１ • 明治時代 • 工場労働者は低賃金 • 給与を上げるには、スキル身に着けて転職 • 大正から太平洋戦争 • 熟練工の長期雇用をしたい • 社内で職工を育成、長期雇用が前提に • 年功賃金制、年功序列制の発生 • 生活給思想が広まる • 若年層に過度な高給を与えても飲食で浪費してしまう • 壮年層には、家族を扶養するために多くの給与を��えるべきだ • 賃金統制令、年功序列が法律で規定される 60 61. 日本の労働法の歴史的経緯２ • 戦後、電産型賃金体系 • 本人の年齢＋扶養家族数をベースに生活給を決定 • これに職能給や勤続給を加えた年功賃金制度 • 占領軍、政府、経営はこれに反対 • 1950年代、職能給の確立 • 技術革新により新規工場が設立、大規模な配置転換が必要に なり、労働者は給与が維持されること条件にこれを労使合意 • 給与の維持＝職能の維持、仕事が代わっても「職能」は変化しない • これにより、労働市場からの人材調達ではなく、 社内の配置転換による雇用調整がメインになる • 「勤続年数が長くなれば潜在能力が伸び、潜在能力があるか ら配置転換しても大丈夫」というのが建前 61 62. 日本の労働法の歴史的経緯３ • 1960～1970年代 • 配置展開が子会社、グループ会社間に拡大 • 転籍という形で企業の枠を超えた異動 • 人事権法理の確立 • 労働者の同意を得ない配置転換を正当とする • 配置転換に本人の同意が必要だとすると、同意を得られな かった場合、労働者を解雇することになる • 一方で解雇権は制限されている • 配置転換と解雇で、配置転換が優先される • ジョブ保障とメンバーシップ保障で後者が優先された 62 63. 日本の労働法の歴史的経緯４ • 1985年 男女雇用機会均等法 • 男性採用・女性採用のラベルを張替えて対応 • 男性採用→総合職 • （家族を養うので）職能給、年功序列で昇給 • コア業務、配置転換あり • 女性採用→一般職 • （結婚までの腰掛なので）昇給しない • 事務業務、配置転換なし • 日本企業は総合職の配置転換によりアジリティを 確保していた 63 64. 日本の労働法と事業会社 • 事業会社は配置転換を前提に従業員を雇用する • 配置転換できそうか？どこに配属しても大丈夫か？ • そしてコミュ力採用に…… • そして産業の高度化について行けず…… • IT人材は社内での配置転換先がないので、雇いづらい • ITシステム開発には稼働の波があるが、事業会社一社ではこれを吸収できない • IT人材を配置転換したいが、配置転換先がない、なので雇えない • IT業務については社外に発注する → SIerへの依存 • 社内にITの専門家がいなくなる • 要件定義、発注、ベンダーコントロールができない • 日本的DX問題に発展、みずほ4500億円… … … 64 65. 余談：追い出し部屋は何故できるのか？ • 日本の給与制度と、労働法の判例が合わさった結果の闇 • 解雇、不当な減給は禁止、でも配置転換はOK • 配置転換をして、自主的に進退を考えるように促すことはOK • 職能が上がってしまって、給与が上がり過ぎてしまった人が生まれる • 職能は「潜在能力（笑）」なので、計測が難しく、年功で上がってしまうことが多い • 職能は「潜在能力（笑）」なので、下げることが難しい • 職能は実際に仕事ができるかどうかは別 • 職能と役職はリンクすることが多いが基本的には独立 • 職能は高いが役職がない、という人が生まれる • リンクさせる必要がある場合、解雇か降格をする必要があるが、これは難しい • 「異動してきたばかりだから、出来なくても仕方ない、そのうち出来るようになるよ…」 65 66. 国内であれば乱暴に出来る 66 http://web.archive.org/web/20180223103231/http://tech.nikkeibp.co.jp/it/atcl /ncd/14/457163/111501934/ https://twitter.com/kumagi/status/966708024491442176 どうして記事が消えてるんですかね？ 67. SI企業の配置転換の事例 67 https://www.nikkei.com/article/DGXMZO37008040W8A021C1TJC000/ 68. 保険事業者が介護事業を買収、配置転換 68 https://www.jiji.com/jc/article?k=2019062401063https://medfit-gl.jp/cw_job/column/1114.php 69. ローテーション人事とプログラミング 69 https://twitter.com/tokoroten/status/617923913964654592 70. 余談：本当にあった怖い話（n=1） • 優秀な新人はプロフィットセンターの生産部門へ • アレな新人はコストセンターのIT管理部門へ • IT管理部門が人材の吹き溜まりに…… • 現場とは話が通じるが、IT部門が30年遅れ…… • 何も考えずに安全側に倒しまくる • データは工場の外に出してはいけない、クラウドなんてもってのほか • ある種のイノベータのジレンマ • 稼いでいる部門に優先的にモノヒトカネを投入 • IT部門に投資して全体の効率を改善するという意思決定ができない 70 71. 分社化される大企業 • 労働者は「同一職能・同一賃金」を期待する • 経営者は「同一労働・同一賃金」にしたい • これを両立させるために、事業・職種ごとに分社化される • グループ会社間で異動させることで、給与を調整できる • 大きく給与を下げるのは判例的にはNG • どこの会社で最初に雇用されたかで給与差が生まれる • 親会社から送り込まれた天下りおじさんが自分の倍の給与をもらっておりモチベダウン • 大企業、本社指向で、そこに人が集まる • あと、ポストを用意したい • 人件費圧縮として行ってきた子会社戦略がDevOps、DXの足枷に • 部署の壁よりも厚い、会社間の壁が 71 72. そして火を噴く日本的労働 • 仕事が高度化、配置転換では対応できなくなってきてる • 配置転換先のない窓際おじさん、パソナルーム、追い出し部屋 • 配置転換をすることで「自発的に退職していただく」 • 先端業務で使える専門性が磨けないローテーション人事 • DXの要請、 2025年の崖 • 仕事の高度化＝コンピュータ時代、全てがコンピュータの時代 • コンピュータが使えないやつに仕事がない時代 • ルールを作って人を管理する時代から、 コードを作ってコンピュータ���世界を管理する時代へ • 機能別子会社による給与抑制は、DXの足枷になる • DXは業務をデジタルによって垂直統合をする • 部署の壁だけでなく、会社の壁にぶち当たる 72 73. CPAの数式でビジネスが語れる世界 • toB、toGov • ビジネスのスケールが限定的、まだ変化速度は遅い • なので、全部が全部、DevOpsにならなくてはいけないわけ ではない 73 74. とはいえ、toB、toGovも変わっていく • 政府のソフトウェアのOSS化 • クラウドの採用、API化 • 入札からコンペ型・直接雇用の契約へ • Industory4.0やConnected Factoryによる事業のAPI化 • 少量多品種生産の増加、全自動フルカスタマイズ生産 • 変化速度が速まっていくことは間違いない • 遅かれ早かれ、WFタイプは減っていくんじゃないかなー 74 75. 例）東京都 新型コロナウィルス対策サイト • Github上でOSSで運営 • https://github.com/tokyo- metropolitan-gov/covid19 • Vue+Nuxt.js+Netlify • SSR かつ SPA • 一般からのPullRequestの 受付 • SIerはこの速度感でサービ ス提供できるか？ 75 https://stopcovid19.metro.tokyo.lg.jp/ 76. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 76 77. 大本営発表マネジメント • 日本的な職能による昇進は、その職位に付く能力があるかない かとは関係なく行われる • マネジメント能力がない人がトップに就くと、大本営発表マネジメン トがよく行われる • 「俺たちは勝っている」というメッセージを発し続ける • 大本営発表マネジメントは、視野の狭い人には強烈に効く • 大半の人は「お気持ち」で働いており、「お気持ち」＝生産性 • 視野の広い人には、強烈なマイナスに作用する 77 大本営発表マネジメントは私の造語なので、ググっても出てきません 78. めんどくさい人々 78 https://twitter.com/tokoroten/status/1235268249723359233 79. 失敗を語れるか？ 79 https://twitter.com/tokoroten/status/1141273917308334080 80. How Not to Land an Orbital Rocket Booster 80 https://www.youtube.com/watch?v=bvim4rsNHkQ 81. ポストモーテム、検死 • 大本営マネジメントは、失敗から学ばない組織を作り上げる • 失敗したプロジェクトを社内でちゃんと話せるか？ • 失敗のコストとは教育である 81 https://landing.google.com/sre/sre-book/chapters/postmortem-culture/ 82. Error Budgetは失敗を許容する • Error Budgetは開発者とSREの間でのインセンティブに使われる • 信頼性100%はあり得ない、誰でも、どんなシステムでも失敗する • Budgetが尽きない限り失敗してもよい • Budgetを設定することで、信頼性を上げすぎて、過剰コストになることを防止する • 失敗が起こることを前提に組織を回すことができる • 失敗をゼロイチで捉えない • SLAの場合、SLAを割ったかどうかでしか評価されない • SLAを下回ったから、謝罪、返金、社長が謝る、終わりの組織は多い • Budgetにして監視をすることで、連続値になり、 意思決定を柔軟に変えることができる 82 83. 学習姿勢と心理的安全性 • How Google Works ラーニングアニマルを採用す る • 自分の能力は変わらないと考えていると、その自己イメー ジを維持するために「到達目標」を設定する。一方、しな やかマインドセットの持ち主は「学習目標」を設定する。 • 学ぶこと自体が目標になると、くだらない質問をしたり、 答えを間違えたりしたら自分がバカに見えるのではないか などと悩んだりせず、リスクをとるようになる。 • ラーニング・アニマルが目先の失敗にこだわらないのは、 長い目でみればそのほうが多くを学び、さらなる高みに上 れることを知っているからだ。 84. プロジェクトアリストテレス • 心理的安全性はGoogleの調査からIT業界に広まった • Project Aristotle チームの生産性に何が寄与するかを調査するプロジェクト https://rework.withgoogle.com/jp/guides/understanding-team- effectiveness/ https://rework.withgoogle.com/print/guides/5721312655835136/ 85. 生産性には5つの要素が必要 • 次の5つが上から順に重要 • 心理的安全性（Psychological Safety） • 相互信頼(Dependability) • 構造と明確さ(Structure ＆ Clarity) • 仕事の意味(Meaning) • 影響(Impact) • 真に重要なのは「誰がチームのメン バーであるか」よりも「チームがどの ように協力しているか」であった※ ※「Googleに採用されている人」という観測バイアスがかかっているので注意 https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/ 86. 心理的安全性の計測指標 • チームの中でミスをすると、たいてい非難される。 • チームのメンバーは、課題や難しい問題を指摘し合える。 • チームのメンバーは、自分と異なるということを理由に他者を拒絶す ることがある。 • チームに対してリスクのある行動をしても安全である。 • チームの他のメンバーに助けを求めることは難しい。 • チームメンバーは誰も、自分の仕事を意図的におとしめるような行動 をしない。 • チームメンバーと仕事をするとき、自分のスキルと才能が尊重され、 活かされていると感じる。 https://rework.withgoogle.com/print/guides/5721312655835136/ https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/foster-psychological-safety/ 87. 心理的安全性とは何か？ • 意訳： 心理的安全性とは、提案をしたり、質問をしたり、懸念してい たり、失敗したことによって、罰せられたり、恥をかかされた りすることが無いことだと信じている状態 https://www.youtube.com/watch?v=LhoLuui9gX8 88. 心理的安全性は何のために必要か？ • ひとことで言うと、心理的安全があれば、厳しいフィード バックを与えたり、真実を避けずに難しい話し合いをしたり できるようになる。 • 心理的に安全な環境では、何かミスをしても、そのためにほ かの人から罰せられたり評価を下げられたりすることはない と思える。 • 手助けや情報を求めても、不快に思われたり恥をかかされた りすることはない、とも思える。 • そうした信念は、人々が互いに信頼し、尊敬し合っていると きに生まれ、そ���によって、このチームでははっきり意見を 言ってもばつの悪い思いをさせられたり拒否されたり罰せら れたりすることはないという確信が生まれる。 チームが機能するとはどういうことか ４章 心理的に安全な場を作る より引用 89. 心理的安全性の勘違い • 「うちの会社は心理的安全性があります！」に意味はない • セクハラだと当人が感じたらセクハラ • 心理的に安全だと当人が感じたら心理的安全 • 心理的安全性は、空間ではなく個人の体感 • 心理的に安全だと感じるラインは個々人で異なる • リーダーは「ここまでやっても安全だ」と見せる必要がある • 自社の失敗をモンティパイソンのBGMで紹介できるか？ • 周りはなかなか変えられない、自分は変えられる • 心理的安全性のラインが高い人を雇用することも大事 90. 個人が心理的に安全になるには？ • なぜ人は発言しなくなるのか？ • 会社や組織と対立することによって、自分の仕事が危うくなると思っている • 日本的な雇用は対立を極端に恐れる • いつ配置転換で地方に飛ばされるか分からないし…… • 会社や組織に対して強くなることでも心理的安全性は改善する • 会社や組織が間違っているのであれば、いつでも出ていける • クビを切られたとしても明日からでも行ける会社がある • 対立したとしてもそれは学習だと認識する • 能力・人脈・転職活動・学習姿勢がある人は、 対立を恐れずにGive firstができる 91. DevOpsが出来る人材を雇用する • そもそもプログラミングが出来ることが必須 • 失敗を学びだと認識できる人 • 目の前の不確かな事象を理解できる言語能力の高さ • 人と対立してもそれを感情ではなく、ロジックで解釈する • 全体最適を意識した動きをするための視野の広さ • HRT、謙虚・尊敬・信頼を持った人 • コミュ力と言語能力は違う • 相手に共感することと、論理的に情報をやり取りする能力は違う • 言語能力が高い人を正しく採用する • これを間違えると、言葉狩り、ポリコレ、コンプラ地獄に陥る • 配置転換を前提とした企業は、コミュ力に寄りがち 91 92. HRT（謙虚・尊敬・信頼） • 優れた開発チームでは、HRTの価値が大切にされている • 謙虚 Humility • 世界の中心は君ではない。 君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。 • 尊敬 Respect, • 一緒に働く人のことを心から思いやろう。 相手を一人の人間として扱い、その能力や功績を高く評価しよう。 • 信頼 Trust • 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば、仕事を任せることができる。 • HRTは学び続け、成長し続けるための姿勢 • HRTの逆を考えてみればよい、人から学ぶことが出来なくなる • HRTを持つことで同僚の行動に対して正しく振る舞える • 同僚は安心して自己を開示し、良い議論が行えるようになる 93. NETFLIXの事例 • 一時ネットフリックスはバッファリング時間（ビデオをクリックして からスタートする��での時間）の短縮に大苦戦していた。エンジニア にしか完全には理解できない、厄介きわまりない問題だ。 • 私たちはセールスとマーケティングの担当者に要請した。「あのくそ いまいましいバッファリング問題をなんとかしてくれ！」とエンジニ アにぶちまける代わりに、「なぜバッファリングにこんなに時間がか かるのか、わかるように説明してくれ」と聞いてほしい、そしてその 質問は本心からぶつけてほしいと。 • 相手がとりくんでいる課題に心から関心をもってする質問は、理解の 架け橋になる。技術系でない従業員は、この質問への答えを通して、 エンジニアがどんなに手ごわい課題にとりくんでいたかを初めて知り、 視野を大きく広げた。 • こうした質問を投げかけるうちに、やがて社内に好奇心と敬意が育ま れ、チームや部門の内外で有益な学習が行われるようになった。いい 加減な噂や陰口のたぐいも減った。 NETFLIXの最強人事戦略4章より引用 94. 余談）IPOでレガシー化するベンチャー企業 • 売り上げを増やすために商品を増やす • 商品を増やすために人を一気に増やす • 人材レベルが低下して、大本営マネジメントが始まる • 市場に対して弱気を見せると株価が落ちる • 市場への強気のアピールは社員の自己洗脳につながる • 対外的なポストモーテムは株価に影響が出ると思い込んでしまう • 社内で失敗の分析や、ネガティブな発言は禁忌となる • 失敗から学ばなくなる • 監査対応でレガシーなシステムが必要になってしまう • 会計監査、内部統制 • 外部の会計会社が慣れ親しんだワークフローを要請される • チェックリスト地獄、監査がレガシー • それをビジネスに組み込んでしまうとシステムが複雑化、レガシー化 94 95. 余談）クソスクラム野郎問題 • 「俺たちはスクラムをしているから勝っている！」と思い込む • 大本営発表マネジメントの亜種 • プロセスを信奉して思考停止する • プロセスは改善するものであり、信奉するものではない • スクラムは「まずは型をコピーするところから始め、自らのビジネス に合わせてカスタマイズしていく」という守破離を説いているが、 そのせいで、守で満足して思考停止してしまう人が多い • 新しいことをするのは怖い、勝ってることにするのは楽 • 「俺はスクラムが嫌いだ」と言うスクラムマスターが何人も… 95 96. SIerはどうなるのか？ • 企業・公共のアジリティを上げる流れ • 公共のOSS化、公共のクラウド化 • 世界は「WFよりも、DevOpsのほうがコストが下がる」ということを 知ってしまった • 柔軟な予算体制を組める組織はそちらに移行していく • 準委任契約の請負とか • ITシステム入札の闇にそろそろ気づき始めている • 結論 • 知ら���がな、うちは単なる中小企業だ、俺に聞くな • 緑の恐竜がだいたい悪い 96 97. 大企業はどうしているのか？ • 既存ビジネスを変更するコストは激烈にヤバイ • 新しい子会社を作るのは簡単 • 新しい人事評価制度、採用ラインで運用 • 最近できたRidgelinez社とか、傍からはそう見える • 既存ビジネスはキャッシュマシンとして現状維持、 新規子会社でチャレンジをする • 現状に危機感を覚えたら、こういうチャレンジをして いる子会社への転職・転属・出向を考えるのもアリ • 富士通クラウドテクノロジーの人にこの辺の話を聞 いてみたい • 富士通標準の業務プロセスをどうやって潰して、 DevOps体制を構築した？ • どのように人材を雇用した？ 評価した？ • 次回の富士通 Tech Liveとかで話してもらったら面白 いんじゃない？ 知らんけど 97 https://pr.fujitsu.com/jp/news/2020/01/30.html 98. 余談：DXできてない企業だと思う事例 • 激ヤバドメイン • なんで富士通が2回？ 階層おかしくない？ • fujitsu.com/jp/ の下にあるべきなのでは？ • コンウェイの法則 • システム設計は組織構造を反映したものになる • 社内政治の壁がドメイン名から透けて見える • 公式ウェブサイトを改修する権限をもらうよりも、 サブドメインを切るほうが楽というのは異常 • 心理的安全性 • 激ヤバドメインにたいしてストップをかけられる 人がいなかったという機能不全感 https://twitter.com/tokoroten/status/1228559664163385346 98 99. 参考資料 • 闇のDevOps DevOpsと業績評価 • https://medium.com/@tokoroten/5aff8b60f589 • xOps: エンジニアがスタートアップの成長の原動力となる日 • https://www.slideshare.net/takaumada/xops • 技術の創造と設計 • https://amzn.to/2VPFaYX • 日本の雇用と労働法 • https://amzn.to/2vxJPDY • How Google Works • https://amzn.to/2TB1J0s • SRE サイトリライアビリティエンジニアリング • https://amzn.to/3cmkvkS 99

[interglacial]

via Twitter https://twitter.com/richard_raw

[rsstotxt]

zakinco nkoz fk_2000

[kjunichi]

管理画面のRailsバージョンをRails4からRails5に上げた話 - Gunosy Tech Blog [はてなブックマーク]

管理画面のRailsバージョンをRails4からRails5に上げた話 - Gunosy Tech Blog

2018 - 02 - 26 管理画面のRailsバージョンをRails4からRails5に上げた話 Rails こんにちは、広告技術部の倉澤です。 普段は広告配信のための管理画面を作ったりしています。 今回はその管理画面をRails5にアップデートした話を書きたいと思います。 この管理画面の first commit は2013年9月17日、 Rails Wayにそってないコードもあり、それなり...

kjw_junichi あとで読む

from kjw_junichiのブックマーク http://ift.tt/2oxxND7

[dothtml5]

電子書籍：これからはじめるWebデザインの本 改訂2版 (Kindle版)

Fetch as Googleからのインデックス送信はMFI移行したサイトではGooglebotをPCとモバイルのどちらを選択すべきか？ (海外SEO情報ブログ)

ユーザーが信頼できる支払い画面を作るための７つのヒント (UX MILK)

UIテストの所要時間を10分の1にする試み、Raspberry Piのクラスタで並列実行 (Publickey)

大量のテキストを食っても速い、Markdown Editorを作った (mizchi's blog)

ブラウザからデバイスに、OSまで！UA判定に便利なライブラリ「UAParser.js」 (LIG)

Vue.jsのライフサイクルとOnsen UIについて (アシアル)

Papercut - シンプルなデスクトップ用SMTPサーバ (MOONGIFT)

チームの継続的改善を支える制度「Kaizen Day」 (Gunosy Tech Blog)

レイアウトで選ぶウェブデザイン・HTMLテンプレート40個総まとめ - 2018年版 (PhotoshopVIP)

商用利用無料！ゼロ戦の機体プレートに使われていた文字を再現した日本語のフリーフォント「FGゼロラバウル」 (コリス)

[siranews]

(hateb!)