The Front-End Tooling Survey 2019 - Results
Front-end development Blog and Portfolio for Ashley Watson-Nolan – Senior UI Engineer at Just Eat It's been a little while coming, but the results from the 2019 Front-End Tooling Survey are now here! This year, 3,005 developers answered 27 questions covering a wide range of front-end tools and methodologies. As always, a massive thank you from me to every single person that took the time to fill i
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
継続的インテグレーション(CI)と継続的デリバリー(CD)について知りたかったら、闘うプログラマを読め - 未来のいつか/hyoshiokの日記
継続的インテグレーション(CI - Continuous Integration)と継続的デリバリー(CD - Continuous Delivery)について知りたかったら、闘うプログラマー［新装版］を読もう。 これはWindows NTの開発物語だ。大規模基盤ソフトウェアの現場の葛藤を生々しく描いていて、ソフトウェア開発に従事しているものには必読書といっても過言ではない。 デスマーチ、ドッグフードを食う、ビルド、業界人なら誰でも聞いたことがあるジャーゴン（業界用語）がちりばめられている。本書によって、それらの用語を覚えた人も少なくないと思う。 「カトラー（開発の総責任者、伝説のプログラマー）は、オペレーティング・システムを開発するときは、機能を増やすより、スケジュールを短縮するべきだと考えている。最初のバージョンは、機能を減らしても、早くリリースしたほうがいい。最初は機能を最小限にして
APIドキュメントを支える技術 - Qiita
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています) APIドキュメントを用意する上で、すぐにぶつかる壁 APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
いけてない設計に出会ったときに考えること - hitode909の日記
どこがいけてないのか？ クラス名とか、機能名とか、概念とか、名前があると考えやすくなる まだ名前なかったら新たな抽象が見つかるかもしれない どんな経緯でそうなっているのか 最初は抽象を捕らえられていたのが拡張を繰り返すうちに失われたのか、書かれた当初は単純な仕様だったのが膨れ上がったのか、動けば良いという感じで書かれたのか 今の設計のいいところは？ 何か意図や事情があってそうなってるのか、動いてるだけなのか 詳しい人や書いた人に気に入ってるところを聞いても良い みんなどう思ってる？ みんなおかしいと思ってるけど手が出せないのか、これでいいと思ってるのか、など雑談して聞いて回る 最高の状態ならどうなってるべき？ 正しいモデリングや、すごい技術があったら、どうなるか 鋭い分析によって豊かなドメインを得られたり、リコメンドシステムなら脳波を読み取って直接推薦してくれたり、変なドアで世界中好きな場
新規サービスの管理画面を短期間で見栄え良く実装する - クックパッド開発者ブログ
こんにちは、クックパッド料理教室の京和です。 管理画面はほとんどのウェブサービスに存在し、ユーザサポートやサービスの状況・KPIなどを確認するために、スタッフが毎日利用するとても重要なものです。にも関わらず、新規サービスでは人員が不足していることから、ついおざなりなデザインや実装になりがちなのではないでしょうか。 今回はクックパッド料理教室で採用している、RailsのMountable EngineとBootstrapのデザインテンプレートを使った、見栄えがよくメンテナンスしやすい管理画面を短期間で実装する方法についてご紹介します。 Mountable Engineとは Mountable EngineはRailsアプリケーション上で動く、ミニRailsアプリケーションのようなものです。 ミニと書きましたが、Railsアプリケーション(Rails::Application)はRails::
Bayonetta2 開発ブログ
Bayonetta2 開発ブログ 『ベヨネッタ２』発売２周年＆amiibo初公開！ 2016.09.20
万葉帰社日に「万葉積み重ね」という発表をしました - タツオチップス
20141010 万葉帰社日発表 万葉積み重ね from tatsuo sakurai 内容 チーム積み重ねっていう前に公開したものと似てる、チーム開発とか社内での工夫とか、あいかわらず僕の好きそうな内容。 なんとなく万葉で中の人達がやってることを小出しにしたいなって思っていたんだけど、どこでやろうかなあ…みたいなのが思いつかなくて、社内で発表した。 万葉は僕にとって働きやすい環境で、なんでかっていうと、自分達で会社の制度や仕組みなどをリファクタリングしたり、機能追加したりしてるからかなあって思う。 もっと効率を良くする仕組みを、効率よく採用できる。（や、まあ、普通にどこでもそうしてますよね…^^;） その理由として、社長が現役プログラマーというのは大きいと思う。（実際社内でも一番書いてるくらい書いてる。っていうのを意外と知らない人がいるって話をちょいちょい聞くのでスライドにもいれてみた。
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
非エンジニアの新卒にプログラミング研修を行いました - pixiv inside [archive]
今年のピクシブ株式会社には総合職 2 人とデザイナー 2 人が新卒として入社しました． そんなフレッシュな新卒に新卒エンジニアがプログラミングの基礎を教えろというお達しが出ました． ということで秋卒業で既に入社していた私（@catatsuy）とアルバイトから入社した 2 人（@geta6/@RooandQoo）の合計 3 人中心でプログラミング初心者向けに研修内容を考えました． 題材 @tarbrick からのリクエストで最終目標は『画像投稿掲示板を作る』ことに決まりました． 方針 今回のプログラミング研修の目的は総合職・デザイナーの人たちをエンジニアにすることではありません． エンジニアの人たちが普段の業務でどういったツールをどういった流れで使っているのかを学ぶことで，円滑にエンジニアとコミュニケーションを取れるようにすることが目的です． そこで方針として以下のものを決めました． 全員
![非エンジニアの新卒にプログラミング研修を行いました - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c5f9cb57c356bd055bcc4941b2635b49e5da47a3/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fc%2Fcatatsuy%2F20140428%2F20140428171910.jpg)
ScaleOut | Supership
「ミライリアルの幸せを、デジタルの力で創る」ことを目指すSupershipグループの社内報です。日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipグループの”Be Super”なストーリーをみんなでシェアしていきます。
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
BEMという命名規則とSass 3.3の新しい記法 - アインシュタインの電話番号
BEMを使った命名がとても明快で、このところHTMLやCSSを書くのによく使っている。CSSのクラス名として書く場合は、BEMをCSS用に使いやすくしたMindBEMdingという書き方を採用している。最初にこれを知ったときは「こんな汚い記述の仕方は使いたくない」と思ってたんだけど、すっかり慣れて、今ではその明快さにちょっと心酔しかけているほど。 BEMの方法論とMindBEMdingのルールについてはそれぞれの文書を読んでもらうとして、それらをひっくるめて大雑把に説明すると、BEMとはBlock、Element、Modifierの頭文字を取ったもので、構成する要素をそのどれかに当てはめて命名していく方法。どの場合でも必ずBlockもしくはそのModifierがルートにあり、その中に、所属するElementもしくはそのModifierが含まれる構成になる。 Block - 構成のルートとな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostCSS とは何か
見積りと計画づくりの技術 / estimating-and-planning-technique
https://prevs.io/
Itamae - Infra as Code 現状確認会
ChangeLog を支える英語
