タグ

Programmingとprogrammingに関するMonMonMonのブックマーク (153)

  • テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita

    テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした: 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま

    テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
  • 絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama

    UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語

    絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
  • Stack Overflow発 プログラミングの隠語(ジャーゴン)30選

    お馴染みのCoding Horrorでプログラミングの隠語(ジャーゴン)についての記事が話題です。 このエントリの元になったのはStack Overflow上で行われた「あなたが新しく作ったプログラミングのジャーゴンはなんですか?(New programming jargon you coined?)」という質問です。この質問にはなんと386もの回答が寄せられ、その中でStack Overflowのコミュニティの投票で上位になった30のジャーゴンをリストにして解説したのがCoding Horrorの「Coding Horror: New Programming Jargon」という記事です。 下記がコミュニティによって選ばれたジャーゴンのリストです。 1. Yoda Conditions(ヨーダ条件式) 変数とリテラルを比較する際にリテラルを左辺に置く記述。スターウォーズのヨーダが「The

    Stack Overflow発 プログラミングの隠語(ジャーゴン)30選
    MonMonMon
    MonMonMon 2017/06/11
    使いたい場面はいっぱいありそうだがヨーダ記法以外は伝わらなそうだな
  • CHANGELOG の書き方 - 角待ちは対空

    VS Code の拡張作っている際に CHANGELOG.md が自動生成され、書き方はKeep a Changelogに従えと書かれていたので紹介する。 ここに書かれていることは絶対ではなくただ提案しているだけである。意見がある人は話し合おうという温度感っぽいので、納得いかない場合は issue 立てると良いと思う。 僕自身はなんでもよくてある程度型が欲しかっただけなのでこれからはこれに従って書いていこうと思う。ただまぁ Semantic Versioning もそうだけどちゃんと従おうとすると以上にだるくなってくるので雰囲気従うくらいだと思う。 CHANGELOG の原則 機械的に生成するのではなく人間の手で書く 各セクションへのリンクが容易にできる 1つのバージョンごとに1つのサブセクションを作る リリースは新しいものが上に来るようにする 日付のフォーマットは YYYY-MM-DD

    CHANGELOG の書き方 - 角待ちは対空
  • レガシーコードの触り方 / Working Effectively with Legacy Code

    オープンセミナー2017@岡山

    レガシーコードの触り方 / Working Effectively with Legacy Code
    MonMonMon
    MonMonMon 2017/05/16
    こだわるな、こだわろう ココが逆になるパターンあるあるなんだよな カバレッジが品質指標になってるとか
  • 外国人が語る:英語でクラスやメソッド等の名付け方 - Qiita

    アメリカ人です。 Hello 👋 この記事の目的 多くの日人は自分の英語力には自信がないではないでしょうか。残念ながら「英語がわからん」、「英語が全然できない」という声をしょっちゅう聞いています。でも、今まで英語ができて意味がちゃんと伝わる何人かの日人に会ったがあります。完璧な英語ではないけど(外国人も英語でミスる時もある...)、がんばって話そうとするので充分仕事ができる人たち。そういうがんばる姿勢はオープンソースのプログラムや英語圏のプログラムに手を出すためには一番大事なことだと思います(外国人側もすごく助かります)。日文化では「私はできる!」と自慢することは少ない中、この記事を通して、流暢に話せなくても自分のプログラミングの命名の仕方にはちょっとだけでも自信を持たせたいなと思います。完璧じゃなくていいです。Let's go! 合わせて読んでいただきたい 【日エンジニア

    外国人が語る:英語でクラスやメソッド等の名付け方 - Qiita
  • 高機能バイナリトレーサqiraはどのように実装されているのか - るくすの日記 ~ Out_Of_Range ~

    1. qiraとは qiraとは世界的なハッカー、George Hotz氏 (ジョージ・ホッツ - Wikipedia) によって開発された高機能バイナリトレーサーであり、qiraという名は(QEMU Interactive Runtime Analyser)の略である。 GitHub - BinaryAnalysisPlatform/qira: QEMU Interactive Runtime Analyser 略語を見れば分かるがuser mode QEMUを使用したバイナリ解析ツールであり、ELFなどの実行形式バイナリを実際に動作させて各命令のレジスタ、メモリへの操作を逐次記録する。 これらの記録はweb UIを通して好きな命令位置にカーソルを移動させるだけで見ることができ、その時のレジスタ、メモリの記録が再現される仕組みになっている。ソフトウェアのデバッグやCTFにおけるバイナリ解

    高機能バイナリトレーサqiraはどのように実装されているのか - るくすの日記 ~ Out_Of_Range ~
  • gitにおけるコミットログ/メッセージ例文集100

    私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

    gitにおけるコミットログ/メッセージ例文集100
  • Archived MSDN and TechNet Blogs

    This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

    Archived MSDN and TechNet Blogs
    MonMonMon
    MonMonMon 2016/06/25
    「そしてモノを考えない人を増やし続ければ、結果的にはその人たちを潰してしまうばかりでなく、巡り巡って自分たちに跳ね返ってきます。」 その通りですね。そんな現場からは良い品質のプロダクトは出せない。
  • 読みやすいREADMEを書く | Yakst

    いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの

    読みやすいREADMEを書く | Yakst
  • バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い

    バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
  • ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について人同意済み。弊

    ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
  • Hayato.io

    Hayato.io This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Top 10 Luxury Cars Online classifieds Healthy Weight Loss Contact Lens Best Penny Stocks Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information

  • 読んで良かった基礎知識の入門書 - Qiita

    Help us understand the problem. What is going on with this article?

    読んで良かった基礎知識の入門書 - Qiita
  • ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ

    ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね! 記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ

    ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
  • はじめてのLisp関数型プログラミング――ラムダ計算からリファクタリングまで一気にわかる

    2016年3月18日紙版発売 2016年3月18日電子版発売 五味弘 著 B5変形判/272ページ 定価2,838円(体2,580円+税10%) ISBN 978-4-7741-8035-9 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle 楽天kobo honto 書のサポートページサンプルファイルのダウンロードや正誤表など このの概要 Lisp・関数型プログラミングのメリットとは何か――副作用のないプログラミングがまず挙げられます。これでバグが圧倒的に少なくなります。さらにはコードの再利用がしやすいこと,並列処理が得意であるということも。それだけではありません。動的な型付けも特徴ですし,ラムダ計算もクロージャも,さらにはオブジェクト指向までできます。数十

    はじめてのLisp関数型プログラミング――ラムダ計算からリファクタリングまで一気にわかる
  • 「コーディングがはかどる」BGMがあるそうです

    「コーディングがはかどる」かもしれないプログラマーの皆さん向けの音楽サイトがあるそうです。ちょっと試してみました。 今、BGMは流れていますか? 家で、電車で、会社で──。「NO MUSIC, NO LIFE」までではないにしても、“ながら音楽”の習慣がある人は多いでしょう。特に論理的な思考を必要とするプログラマーの皆さんは、良いコードを効率よく書くためにどんな環境が必要か、どんな音楽だとはかどるか、それぞれ自身の方法論を持っていると思います。 例えば、アマゾンの定額制音楽配信サービス「Prime Music」には、「~~のための音楽」といった、あるテーマに沿った楽曲を集めたプレイリストがたくさん登録されています。「ドライブに最適なJ-POP」「お休み前に聴くピアノソロ」「恋がしたくなるJ-POP」などの他に、「仕事がはかどるジャズ」「残業を乗り越えるサントラ」「満員電車でイライラしないポ

    「コーディングがはかどる」BGMがあるそうです
  • 【保存版】プログラミングで使うやたら難しい英単語のかんたん解説15選

    プログラミングでコードを書くときは、99.9%英語を使いますよね。 クラス名やメソッド名をつけるのにも、欠かせません。 ですが、他人が書いたプログラムを見たとき、あなたはそこに書かれている英単語の意味を当に理解していますか? 知らない単語が混じっていて、困惑したことはありませんか? fetch、acquire、retrieve…。 「よく分からないけど、まあいいや」ではすまされない! コードの破綻を防ぐためにも、ここでばっちり、知らなかった英単語の意味をマスターしていきましょう! 機種変更では、このような失敗をする方がとても多いです。 有料オプションを契約させられ料金が高くなった。。 待ち時間や契約時間が長くて、半日かかってしまった。。 キャンペーンや割引がきちんと適用されていなかった。。 スマホを乗り換えるときには、 → おとくケータイで乗り換えキャッシュバックをもらう で乗り換えをす

    【保存版】プログラミングで使うやたら難しい英単語のかんたん解説15選
  • Hackster.io - The community dedicated to learning hardware.

    Hackster is hosting Impact Spotlights: Industrial Automation. Watch the stream live on Thursday!Hackster is hosting Impact Spotlights: Industrial Automation. Stream on Thursday!