無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。 例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることが
Vue.jsのmixinをslotで代用する - Qiita
Vueにはmixinという機能がある。 同一の機能を複数のコンポーネントに適応させるというものだ。 共通の機能を提供する便利なものだが、あまり楽観的に使えるものではない。 例えばReactでも過去には存在していたが、既に廃止されている。 なぜ廃止されたかは理由を読めばmixinのどのような点が危険な点かが見えてくるだろう。 https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750 ざっくりと要約するとこのへんが上げられている 暗黙の依存関係を導入してしまう 名前の衝突を起こす 複数のmixinがあり、それらがプロパティを上書きす
私は jQuery から Vue.js への置き換えで何をやらかしたのか - Qiita
東京の皆さんこんにちは。ご機嫌いかがでしょうか？ 私は今、旅行に来た新潟のホテルでこの記事を書いています。うまい酒にうまいメシ。なぜ我々は東京に固執するのでしょうか？私は今最高に幸せ（ 忘れてた 時間がなくて終わっていないアドベントカレンダーの原稿書きがなければもっと最高だったのに）です。美味しい日本酒のおかげで捗るこの記事は、きっと 12/2 に公開( 追記: ダメでした )されるでしょう。 さて、表題の「私は jQuery から Vue.js への置き換えで何をやらかしたのか」について語って行きましょう。ちょうどアルコールも入っているし、色々語れそうです。 忙しい人向けまとめ Q. jQuery でがっつり UI 組まれた Rails アプリで脱 jQuery を図るなら、気をつけないといけないところはどこでしょう？ A. 本当に jQuery が問題なのかよく考えましょう jQuer
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
Java初心者時代にコードレビューで指摘された悪しき習慣 - Qiita
Java初心者だった新入社員の頃、先輩にコードレビューで指摘された事を思い出してまとめてみた。 追記：本記事に関しては賛否含め、多くの有益なコメントを頂いています。本記事をお読みになる際は、是非コメント欄も併せてご覧下さい。 2018/04/26 コメントを参考に「何でも定数にしようとする」の見出し・本文を修正しました。@kagilinn さん、ありがとうございました。 2018/04/30 サンプルコードの判定バグってたので修正しました。@y_miz さん、ご指摘ありがとうございました。 コメントの誤記、用語誤りを修正しました。@scivola さん、編集リクエストありがとうございました。 不要なインスタンス変数を作ってしまう インスタンス変数は状態が保持されるので、バグを作り込みやすい。 「これローカル変数でよくない？」ってよく指摘された。 インスタンス変数を作る前に、ローカル変数で実
まだAWSのみに頼って生きてるの？複数のクラウド利用で、大幅コストダウンした話 - Qiita
by @mixiappwchr 一人でがっつりAWSでサービス開始しましたが、運用を始めると多くの問題が起きえます。 今回はコストに対する問題を,AWSだけでなく、他のクラウドを活用することで大きく削減できたという事例を共有したいと思います。 例えばNetflixが Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開 といったオープンソースを公開していることを鑑みるに、すでにマルチクラウドでの運用は行われていることでしょうし、今後はこういった事例も多くなっていくことでしょう。 クラウドを複数使うにあたった経緯 前回 goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 といった記事でリリースしたおしゃべりマルチというサービスですが、おかげさまでユーザー数も順調に増え、利用者に楽しく使っていただいてお
ひとりぼっちのサービス開発における技術選択の遷移と戦略 - Qiita
by @appwatcher 以前下記で書かせていただいた goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 ですが、上から下まですべてを担当して個々の技術をすべてやった経験自体も勉強になったのですが、 どうして、そのような技術選択をしたか？という点が自分でも振り返ってみて学ぶ点がありました。 それぞれ良し悪しがあったので何かしらの参考になればと思い、それ以後の技術変遷や取捨選択を踏まえて、振り返ってみたいと思います。 なにかしらの参考になれば。 ちなみに未だに一人です。 今回の技術選択をした時の基準や自分なりの戦略 スピード重視。これは今回に限らず自分自身の戦略です。基本通常の人の３倍のスピードでやる気概でやってます。 ユーザーグロース重視。これはサービス立ち上げからやるので当然。 コスト重視。今回フリーになってコストまできちんと意識するようにな
工数見積もりのコツ - Qiita
はじめに 本稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい
4つの戦犯から考えるサービスづくりの失敗
「リンスタ関ヶ原 〜敗軍の将、兵を語る編〜」で話したこと。 https://devlove.doorkeeper.jp/events/66102Read less
労働条件を改善するためにやったこと全部話す。 - Everything you've ever Dreamed
この春から営業の責任者になる。高く売り込み、評価して貰って入った会社であり、突然、あーっ！と奇声をあげたり泣きだしたりする同僚もいない、実に働きやすい環境でもあり、出来るだけ長いあいだお世話になりたいと思っている。給与も上がるし。だが、半年ほど働いてみて、これからも働いていくためには契約上で問題になりかねないことが見つかってきたので、ボスに改善を訴えた。 僕の労働条件をざっくり説明すると、年俸制で、そこに残業代は含まれている。僕は管理職である。管理職は労基法上の管理監督者は違う。労基法上の管理監督者には残業代を支払なわなくてもいいことになっているが、それは非常に限定的な定義で、認められるには、１．経営者との一体性、２．出退勤の自由、３．ふさわしい待遇が備わってなければならない。ほとんどの管理職は管理監督者とはされない（と思われる）。前の会社はブラックだったので、管理職は基本的に管理監督者と
null安全を誤解している人達へのメッセージ - Qiita
先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃんとやらないと、コンパイルが通らないからです。
「サロゲートキー vs 複合キー」という間違った対立 - ネットの海の片隅で
DB設計についてググっていると、「サロゲートキーは使うべきではない」や「複合キーは使うべきではない」といったDBのキーに関する論争をよく見かけます。 それらを見ていると、多くの議論で「これって対比の軸がズレてないか？」と思いました。 正しい対比 正しいと思う対比とそのざくっとした意味。 自然キー vs 代替キー 自然キー（Natural key） キーそのものに意味が含まれているキー。 都道府県を含むテーブルprefecturesがあったとして、都道府県名prefectures.nameは自然キー。 代替キー（Surrogate key）*1 キーそのものには意味が含まれていないキー。 前述のprefecturesの例で言えば、システム内部のみで使用されている都道府県コードprefectures.codeは代替キー。*2 単一キー vs 複合キー 単純キー（Simple key） 単一のカ
Pythonの仮想環境構築 2017.01版 - YAMAGUCHI::weblog
はじめに こんにちは、Python界のテリー・ギリアムです。こんな記事を見かけて、Pythonの開発環境を作るのが面倒という認識が広まるのは良くないなあと思って書きました。ただの突っ込み記事です。 qiita.com そのツールほんとに要りますか？ 出だしにこんなセクションタイトルがありました。 その仮想環境本当に必要ですか？ たしかに仮想環境要らないひとは要らないよねっていうのは同意です。その場合、入ってるPythonのsite-packagesにどんどんパッケージがインストールされるだけなので、手動で消せる人はそれでいいし、そもそもパッケージのバージョンとか知るかって人はそのままパッケージインストールすればいいと思います。 とはいえ、複数のプロジェクトでパッケージのバージョンがぶつかったら困る人とかいるし、そういう人は仮想環境を使うことになるでしょう。で、件の記事ではいろいろなツールを
平滑化スプラインと加法モデル | Logics of Blue
最終更新：2017年03月11日 Rを用いた平滑化スプライン・加法モデルの簡単な解説と計算・予測方法を載せます。 単回帰・重回帰分析との比較を交えて説明します。 ここで用いたRコードは、まとめてこちらから見ることができます。 コードは2015年8月30日に動作確認をしました。動かないものがあれば、ご一報いただければ幸いです。 スポンサードリンク 目次 １．平滑化スプラインと加法モデル ２．平滑化スプラインの仕組み ３．グネグネ度（平滑化パラメータ）を推定する ４．Rによる平滑化スプライン ５．線形？ それとも非線形？ ６．グネグネ度の決め方 ７．モデルチェック ８．薄板平滑化スプラインと平滑化スプラインANOVA ９．加法モデルによる予測 ～重回帰との比較～ １．平滑化スプラインと加法モデル 平滑化とはなんでしょうか。正確な定義ではありませんが、ものすごく簡単に言うと、「散布図にニョロニョ
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
ドイツの受託開発会社を退職しました - WETな備忘録
2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
脆弱性ハンドリングと耐える設計 -Vulnerability Response-
フロントエンドのスキルマップと育成のはなし
バグハンターが見てきたBug Bountyの7年 / LINE Developer Meetup #34 Security Bug Bounty
セキュリティ教育とUX ～結ばれていた赤い糸～
