タグ

コードに関するotakumesiのブックマーク (27)

  • LIVESENSE ENGINEER BLOG

    2024-01-12 紹介型マッチングアプリknewにおける好みの個人差 knew データサイエンス 目的 マッチング精度 好みの個人差が反映されやすい評価項目 データ 分析方法 結果 容姿の好み 容姿整い度:女性は個人差が大きいが、男性は容姿が整っていないことを許容しない 美人度:女性皆かっこいい人が好み、男性20代で個人差が大きい 顔の濃さ:女性… #マッチングアプリ #knew #knew(ニュー) 2024-01-09 【非データサイエンティスト向け】階層ベイズのイメージと使いどころ データサイエンス ユースケース 例1:企業別の想定提示年収(平均値) 状況 グラフ データ 問題設定 例2:求人別の採用率(比率) 状況 グラフ データ 問題設定 例3:企業別の高評価特徴(回帰モデルの係数・切片) 状況 グラフ データ 問題設定 階層ベイズのイメージ 少しだ… #データサイエンス #

    LIVESENSE ENGINEER BLOG
  • 学校では習わないコーディングスキル:オブジェクト所有権 | POSTD

    プログラマとして身に着けるべきスキルはたくさんありますが、中には、ソフトウェアエンジニアリングの標準カリキュラムに組み込まれていないものもあります。そうしたスキルは少しずつ自然に、あるいは経験豊富な人と一緒に仕事をする中で学ぶ必要があります。1つDavid MacIverが取り上げているのは、 値の型を追跡するスキル です。 他には、コード中のオブジェクト所有権を理解するスキルも必要です。つまり、コードのどの部分がメモリ内の特定オブジェクトを所有し、それがどんなアクセスを予期しているかを知るということです。 その理解なしにコードを書くと、プログラムがクラッシュしたり厄介なバグに悩まされたりすることになるかもしれません。さらに悪いことに、プログラミング言語の中には、この問題に役立つ手段さえ提供してくれないものもあるでしょう。 自然に身に付ける これは、私がこのスキルを学んだ方法です。私は大学

    学校では習わないコーディングスキル:オブジェクト所有権 | POSTD
  • ディープワークの本 - hitode909の日記

    ディープワークは邪魔されず集中して取り組めて,価値あることを成し遂げるような仕事,シャローワークは,メールに返信したりとか,事務作業みたいな仕事.ディープワークが大事,という. 邪魔されないようなライフスタイルの組み立て方も載っていて,「インターネットしない日を作る」ではなく,「インターネットする時間を決める」とか,けっこうストイック.SNSを使うべきかどうかという議論も載っていて,目標を直接支援しないならやめましょう,ということだった.クヌース先生はメールを使わないことで,ディープワークに集中できている. クヌースにツイッターのフォロワーをつくることや、もっと自由なメールのやりとりで生まれるかもしれない予想外の好機を売り込んでも無駄だろう。これらは直接、彼の目的の助けとはならないからだ。 ソフトウェア作ってるチームでチーム歴が長くて便利な人になっていくと,Slackで絶えず話し続けて,

    ディープワークの本 - hitode909の日記
  • 継続してコードを書くということ

    この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視1年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 1年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると

    継続してコードを書くということ
  • エンジニアの10大ウソ · dongri

    後でコメント付けるから これは暫定的な方法、番リリース時はこの方法で書かない 大体終わった。後小さい問題何個か残ってるだけ エンジニア:”十日は必要”。Boss:”五日でできる?”。エンジニア:”できる!” TODO 私の端末ではちゃんと動くのに これはテストする必要ない、絶対問題ないから そう、もうテストした 一行の修正だけ、他の処理に影響しない これは前からあった問題 追加10ウソ 次コード修正する時ユニットテスト書くよ 90%は終わった これは二分で解決できる そう、これは既知のBugだ 昨日はちゃんと動いてたのに そんなのありえない これはハードウェア/ネットワークの問題、私のコードと関係ない これはBugではなく、特性だ 私は今ドキュメント読んでる 私はサボってない、今ビルド中

    エンジニアの10大ウソ · dongri
  • MySQLの文字コード事情 2017版

    "Портирование Web SDK с JS на TS" Петров Григорий, Voximplantit-people

    MySQLの文字コード事情 2017版
  • エンジニアが知っておいて損は無さそうな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

    エンジニアが知っておいて損は無さそうなISOの標準規格たち - Qiita
  • JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD

    この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

    JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
  • インフラ部門で働くCプログラマの話

    12. miruo Pretty-Print TCP session monitor/analizer miruo を⼀⾔で説明するなら「⾒やすい tcpdump」です。当社⽐10倍です、ISUCON 勢に オススメです。TCPセッション毎にパケットをまとめて出⼒するため、パケットの流れが格 段に追いやすくなります。また、問題のなさそうなパケットはあえて省略して表⽰しないの で、興味のありそうなパケットだけが出⼒されます。 $ ./miruo --all -i en0 -m http tcp port 80 listening on en0, link-type EN10MB (Ethernet), capture size 1522 bytes 0001 0.048 | 10.0.0.100:62511 == 125.6.190.6:80 | Total 21 segments, 133

    インフラ部門で働くCプログラマの話
  • GitHubのコード検索 : プログラマにとっての宝の山 | POSTD

    新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します(またはソースコードを丹念に調べます)。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか? 「誰かが既にこの問題を解決しているはずだ!では、なぜこの問題に対する答えがStack Overflowにないのだろうか?」 そのとおりです。恐らく誰かは既にそれを解決

    GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
  • 天才プログラマーと自分との実力差をカンタンに測定する方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

    天才プログラマーと自分との実力差をカンタンに測定する方法を発見しましたよ、という話。 結論から言うと、いろんなところで過去に開催されたプログラミングコンテストの入賞者の結果を見て、その問題を同じ条件で解いてみること。 あるウェブサイトに2015年に開催されたプログラミング・コンテストの結果が載っていた。(記事の末尾にそのプログラミング問題の日語訳を載せた) 入賞者は1位の人が15分、2位が22分、3位が24分、となっていた。 プログラミングの問題をザッと眺めていたら、実装すべきアルゴリズムがパッと思いついた。「これはひょっとして1位の人は超えられなくても3位入賞ぐらいはいけそうじゃね?」などと考えてしまった。 それでそのウェブサイトが用意しているエディタを使って、コードを書きだした。 15分経過:「あれ?もう15分も経った?まー1位にはなれなくてもトップ集団には入るわ」 20分経過:「

    天才プログラマーと自分との実力差をカンタンに測定する方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
  • bkノート

    Google+に書いていたエッセイのアーカイブです。 すぐ置き換わるから大丈夫 #62 TeXの思い出 #61 Welcome to the industry! #60 ビルドという名のトンネル #59 キーボードを替えた話 #58 テストを実行するとログインシェルから追い出される問題 #57 シークレットストーリー #56 ドットコムバブルの思い出 #55 コミュニケーション能力とは何ぞや #54 メールで時間を無駄にしない方法 #53 パッチの数え方 #52 zipファイル中毒 #51 はじめてのIPv6 #50 最近の毛刈り #49 練習してもっと速くやるべし! #48 忍耐力指向プログラミング (Patience Oriented Programming) #47 VPNの謎 #46 ウェブプログラマへの道 #45 プログラムの見通しをよくする方法 #44 パイプがなぜか詰まってし

  • やっぱブロックチェーンダメっぽい

    デジタル台帳「ブロックチェーン」が支える仮想通貨ビットコインを何百万人にも紹介したステファン・トーマス氏は、心変わりした。 この記事、最初見たとき釣りかと思ったけど、釣りではなく「まあそうだよね」と言う意見だった。 ここで言われてるのは 金融機関の政治問題合意形成コストの2つが課題でブロックチェーンが実戦に不向き的なこと。 1個目は人の問題なので置いとくとして、2個目が散々。 計算にマシンパワーが必要なのと、その結果を全ノードに等しく伝えるのに何日もかかる & その過程で生じた履歴がもし採用されなかったら破棄される可能性もある。 これらの点から「速くて、堅牢な、低コストの取引台帳」なんてものはないの明らかなので、登壇テーマとして用いた身なのを棚に上げながら言うと、すぐさまこの界隈は沈静化してほしい。 ハッシュ値を最も早く生成し、その結果その解答者以外の履歴はあっていようが間違っていようが場

    やっぱブロックチェーンダメっぽい
  • クソコードにならない為に、これだけは守って欲しい7つのこと - Qiita

    まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので1つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概

    クソコードにならない為に、これだけは守って欲しい7つのこと - Qiita
  • 初心者でもカンタンにRailsの中身のコードをコードリーディングする方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

    ここで言う「Railsの中身のコード」というのはRailsを使ったRailsアプリのコードのことではない。Railsそのもののコード。DHHが書いたRailsのコード。$ rails new AppNameとかのコマンドが動く仕組みが書かれたコードのこと。 これって職場の同僚と英語で話しててもいっつもゴチャゴチャと説明が要る。RailsアプリのコードとRailsの中身のコードを区別してそれが一発で分かってもらえる表現があったら教えて欲しい。 既にご存知の方はたくさん居ると思うがそのRailsの中身のコードというのが巨大でなかなかにレベルが高い。初心者では読むのも一苦労でそこが遠ざけてしまう原因にもなっている。それでも優れたコードをコードリーディングすることはエンジニアにとってとてもいい勉強になるのでオススメ。 いかにコードリーディングが重要かは、いろんなブログなんかで優秀なエンジニアの方々

    初心者でもカンタンにRailsの中身のコードをコードリーディングする方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
  • 私がコーディングで垂直方向にそろえるインデントをとる理由 | POSTD

    先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは? 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ

    私がコーディングで垂直方向にそろえるインデントをとる理由 | POSTD
  • http://post.simplie.jp/posts/34

    http://post.simplie.jp/posts/34
  • よいコードを書くために,プログラマは何をすればよいのか

    よいコードを書くためには,設計の基を守り,既存のコードを読むことが必要である – Java ChampionでハイパフォーマンスコンピューティングのスペシャリストであるMartin Thompson氏のことばだ。InfoQは,QCon London 2016で“Engineering You”と題した講演を終えた氏に,ソフトウェア産業が直面する課題は何か,プログラマがそれを克服して優れたソフトウェアエンジニアになるにはどうすればよいのか,などをインタビューした。 InfoQ: 講演の中であなたが引用した,1986年の,ソフトウェアエンジニアリングに関する最初のNATOカンファレンスの内容は,現在でも通用します。ソフトウェア産業がいまだ問題を解決できないのはなぜでしょう? Martin Thompson: 1986年のNATOカンファレンスには,たくさんのテーマがありました。彼らはソフトウ

    よいコードを書くために,プログラマは何をすればよいのか
  • 状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない?横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になりになり死

    状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • Linuxカーネルのコードを読んで勉強になったこと - φ(・・*)ゞ ウーン カーネルとか弄ったりのメモ

    Linuxカーネルのコードを読んでて、なるほど〜と思うことはよくあるけど、その中でも特に今までの考え方をぶち壊してくれたのはなんだっけと思ったところ、やっぱりリスト構造かなと言うところ。 c言語でリスト構造を作る場合、一般的な教科書方式だと↓のようにデータとnextポインタは密結合になってると思います。これの場合、struct foobarのポインタをnext要素に使っているので、他の構造体(例えば、struct hogehoge)で同じことをしようとすると、その構造体ではstruct hogehoge *nextというメンバ変数を持つ必要があります。 ヘッド要素はstruct foobarです。 struct foobar { int n; char s[64]; struct foobar *next; }; struct foobar head; Linuxカーネルの場合、データとリ

    Linuxカーネルのコードを読んで勉強になったこと - φ(・・*)ゞ ウーン カーネルとか弄ったりのメモ