エンジニアが披露宴の余興を頼まれたら - Qiita
先日、知人の結婚披露宴にて初めて余興というものを依頼され、なんとか乗り切ったのでその時のこと。 どうしよう なにか持ちネタがあるわけでもない。 歌や踊りが達者なわけでもない。 ムービーは多少作れるけど、新婦側の余興でやるらしい。。 ： プログラミングしかない！！ やったこと 『HAPPINESS SCOUTER（ハピネス スカウター）』 LINEで写真を送ると、写っている人の表情を認識して『幸せ戦闘力』を測定します！！というもの。 （前回の記事で書いた、Amazon Rekognitionを使用したLINE BOTの延長です） 送ってもらった写真の一覧と詳細を見れるページも作成し、 一覧ページでは幸せ戦闘力のランキング形式で表示するようにしました。 【LINEの画面】 【詳細ページ】 【一覧ページ】 用意したもの LINEアカウントと一覧ページのQRコード 名刺サイズのカードを人数分用意し
そろそろSQLのウィンドウ関数を理解したい - 連載1/3話 - Qiita
はじめに データ分析とデータ品質改善に従事してきた筆者が、SQLを用いた分析の基本である「ウィンドウ関数」の使い方とデータ品質の調査改善を行う手法をまとめてみようと思います。 こちらの記事は、SQLの知識向上と振り返りを主題としているので、ABC分析、バスケット分析、RFM分析などの「データ分析の手法」について説明している記事ではありません。(反響やコメントによって別投稿するかもしれません) 背景 SQLはエンジニアの大多数が利用しており、多くの方はWebサービス開発などでデータの登録画面や検索画面を作る際にSQLを利用したり、またはシステムの運用保守で障害の原因調査のためにSQLを利用して原因を特定すると思います。そのため、テーブル結合・サブクエリ・集計関数といったSQL構文は理解されている人が多いと思いますが、分析関数を理解して使っている人となると、ぐっと減ると思います。 私は以前、社
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
