ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
いつものように本番作業してたはずなのに - Qiita
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景（前提条件） いっていに昔の話です ETL（データ加工）サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境
日本の組み込み業界に未来はないかも、と思わせる上司の発言集
はじめに とある企業で組み込み系ソフトエンジニアとして働いていますが「このままだと、将来ないかも？」と思えてくる場面に日々遭遇します。 今回は日本の組み込み業界の将来が不安になる、耳を疑った”上司の発言”をまとめてみました。 「最近の若いやつらは残業が足りない」 働き方改革が騒がれるこの時代に、そんなこと言う人いるの！？ と驚く方もいるかもしれないですが、いるんです。 そして、それがまかり通る現場の一番の問題は 「開発業務の効率化、スピードUPを図る文化が根付かない」ことだと私は思っています。 「時間が足りなければ残業でカバーすればOK！残業代も出るし、いいでしょ。」 という考え方では、どうすれば開発スピードが上がるか？無駄な作業はないか？自動化できることはないか？といった改善のアイデアは、なかなか出てきません。 残業を推進し次から次へと業務が積まれていくような現場では、改善のアクションの
フリーランスエンジニアの単価を決める - Qiita
記事概要 書いた目的 フリーランスエンジニアの単価設定に「情報の非対称性」ある フリーランスは市場動向掴んで「売り手」になるべき エンジニア応援したい、優秀なエンジニアは年収伸ばせば良いし、キャリアミスマッチしてるエンジニアは再構築すれば良い 読者想定はフリーランスエンジニア、qiitaに多そうだから投稿 記事の内容 1. 自分のプロフィールと単価を公開 前職年収900万円で、フリーランス日額6.5万円〜10万円 40社ぐらい営業して、1/3は話が進む 2. この単価設定にした根拠を説明 前職基準、採用市場、派遣、フリーランス市場、英語圏 3. 終わりに 「こんな人材求められてるんじゃないかな」、「こうしたらキャリア積めるかも」を記載 正社員に戻って修行するなら、開発チームが強い（CTOが役員として存在）イケてるWeb企業で正社員キャリア積むことを目指すべき フリーランスのままでも「チーム
GitFlowをやめて本番リリースが楽になった話 - Qiita
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
理不尽なリジェクトを受けたiOSアプリが公開されるまでの経緯 - Qiita
はじめに あなたが作成したアプリを多くのユーザーに利用してもらうにはモバイル・アプリ・ストア (Apple の App Store や Google Play など) を通じてアプリを配布することが最適な方法です。 しかし、App Store にアプリを公開するためには、Apple のレビューを避けて通ることはできません。Apple のレビューは彼らが自ら定め、公開されているガイドラインにもとづき、評価が下されます。 ほとんどの場合において、彼らのレビューは適切に行われていると言えますが、ごく僅かなケースにおいては理不尽な評価が下される場合もあります。アプリに対して理不尽な評価が下されると、それを覆すことは難しく、最悪の場合アプリの公開を断念しなくてはなりません。 この記事では、理不尽なリジェクトを受けたあるアプリが、AppStore へ公開されるまでの経緯を説明しています。 アプリの開発
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
iOSアプリ開発の全体像 - Qiita
超技術書展で頒布したiOSアプリ開発の全体像をだらだら書いた本を記事として公開。 ただのポエムです。 2年くらいまえに、SwiftもObjCも一切書いたことないし、アプリも一回も作ったことがない状況でiOSアプリを作ってリリースするミッションのお仕事が降ってきたので、そのときにこんな情報があったら全体が見通せて、気持ち的に楽だったなと思った内容をまとめました 1. iOSアプリ開発を取り巻く環境 iOSアプリ開発には、基本的にmacOSを搭載したコンピューターとXcodeとよばれるソフトウェアが必要です。もともと主にObjective-Cという言語が使われるケースがほとんどでしたが、2014年6月にAppleがプログラミング言語Swiftを発表して以後の新規開発には、ほとんどの場合Swiftが採用されているようです。またSwiftは、Objective-Cのコードと共存できるため、もともと
簡単にガントチャートとかクラス図とか書けるやつ - Qiita
mermaidは、Web上で簡単にフローチャートやシーケンス図などのUMLが描けるライブラリです。 d3.jsの機能特化型というかんじで、d3ほど様々なことはできませんが、そのかわりに対応してる図形なら非常に簡単に描くことが可能です。 なお、ヘルプはGitGraphやクラス図が載ってないなど未完成で、いまいち頼れません。 ごたくはいい、実物を見せろ こんなかんじ →支払い忘れてサーバが死んだので代替(誰かが書いたやつに勝手にリンク) できること 以下の図が描ける。 ・フローチャート ・シーケンス図 ・ガントチャート ・クラス図 ・gitグラフ 最後だけ異質だ。 インストール CDNを使えばいいだけだが、自分のところに置きたい場合はyarnで引っ張ってこれる。 <!DOCTYPE html> <html lang="ja"> <head> <link rel="stylesheet" hre
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ
不思議の国のSE用語 - Qiita
不思議の国 SEが住んでいるところ、そこは不思議な不思議なお国柄です。 新たな国民として移住してきた人、特産物のシステムを買いに来た人など色々な人がこの国には存在します。 しかしこの国で話される言葉は 独特 です。 ぱっと聞いただけでは意味がわからなかったり、よく似た表現であっても微妙にニュアンスが違っていたり。 似たような表現を使い分けるその裏に、その人の意図や省略された文脈が隠されていたりもします。 どこの国でもコミュニケーションを間違うと非常に厄介ですが、そんなことにならぬよう、 お国言葉らしきもの をまとめてみました。 SEを代表例として、このお国言葉を話す人も、話される人も、改めて言葉の意味合いを見つめなおしてみると新たな気付きが得られるかもしれません。 なお、そんなことから 「絶対にSEしか使わない用語」を集めたわけではない のでその点ご了承くださいませ。 他言語版 @micr
[社内新人向け]Gitで使ってほしくないコマンド - Qiita
社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。 本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。 (追記：第二弾できました) → [社内新人向け]Gitで絶対にオススメなプラグインや設定3つ 社内環境 Web系開発がほぼ100％ ブランチワークはGitflowをベースにしたプルリク駆動開発 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい（vagrantや開発サーバ上の操作など） GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました CIツールはまだ導入できず。各サーバーへのデプロイ
![[社内新人向け]Gitで使ってほしくないコマンド - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c02b564a55050853439b0f6986d3aa42501396d4/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUE0JUJFJUU1JTg2JTg1JUU2JTk2JUIwJUU0JUJBJUJBJUU1JTkwJTkxJUUzJTgxJTkxJTVER2l0JUUzJTgxJUE3JUU0JUJEJUJGJUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJUJCJUUzJTgxJTk3JUUzJTgxJThGJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgyJUIzJUUzJTgzJTlFJUUzJTgzJUIzJUUzJTgzJTg5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz00YzYzNDI4NzA3YjAxYTI4Y2QzMzAyOTFjYzQzMTkxYQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB6YXJhbW1lJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mZDc5M2U2Y2U4OTg4ZTM4OTI2YmE3NDkyOTc1MDJkZQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dc30c566ec78e040079beb6919643238f)
エンジニアが知っておいて損は無さそうなISOの標準規格たち - Qiita
「それ○○で標準化されているよ」って指摘されることほど、エンジニアにとっての屈辱は無いですよね。 ということで、世間知らずだと思われないためにも、手始めにISO縛りで有益そうな標準規格1をまとめてみました。 ちなみに、ISOとは…？ 国際標準化機構（International Organization for Standardization）は国際規格を策定する世界最大のボランタリーな開発組織で、国家間に共通な標準を提供することによって、世界の貿易を促進することに貢献している という組織だそうです。 (どう考えてもIOSと略すべきだと思うのですが、ISOになった理由は諸説2あるようです。) コード体系 ISO 639 (言語名コード) 例: 日本語 = ja, jpn 朝鮮語 = ko, kor 中国語 = zh, zho, chi, zho ドイツ = de, deu, ger, deu
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
SIの現場のiOSアプリケーション開発 - Qiita
どうも、SIerのシステムエンジニアです。 システムエンジニア Advent Calendar 2016の11日目です。 10日目は deaf_tadashiさんの「聞こえないシステムエンジニアが心がけていること」でした。 はじめに 直近は金融系の新サービスのバックエンド側の開発をしていました。 会社で利用する言語はほとんどJavaで、iOSだとObjective-Cを遊び程度でさわったことがある程度です。 現在チームメンバーは5人で、スクラムで開発を進めています。 ※ 厳密にはふつうの受託開発のやりかた をチームに合わせて拡張したものです ほとんど経験の無いiOSアプリケーション開発をいきなり任されたので、基本的には以下のような方針で物事を決めています。 世の中で実績があること アーリーアダプターしか触っていないようなものは避ける ある程度安定していること とはいえ新しい技術であること
技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub English Challenge Cheat Sheet - Qiita