タグ

Programmingとdevelopmentに関するVoQnのブックマーク (35)

  • Bayonetta2 開発ブログ

    Bayonetta2 開発ブログ 『ベヨネッタ2』発売2周年&amiibo初公開! 2016.09.20

    Bayonetta2 開発ブログ
    VoQn
    VoQn 2014/11/21
    カッコイイ。ゲームプログラマーはそういうカッコイイことした話が良い
  • ページ移転のお知らせ

    ユークエスト株式会社は2021年10月1日をもちまして、 株式会社東光高岳に吸収合併を致しました。 Webサイトは下記のURLに移転しました。 https://uquest.tktk.co.jp/ ※5秒後に移転先にジャンプします。

    VoQn
    VoQn 2014/11/11
    組み込みの基礎的な話からメモリ管理やレジスタ制御まで広範に解説してくれている
  • LLVMによるプログラミング言語の実装 – 日曜研究室

    最近の投稿 問題: 積み木を10個積み上げるのにかかる時間は 2020/8/20 木曜日 Google の G Suit Team から “[Action Required] Remove internal links to the G Suite Domain Contact page for your organization” ていうメールが来た 2020/8/14 金曜日 NZXT H1 と ROG STRIX B550-I GAMING で組んでみた 2020/7/17 金曜日 花粉症対策2019 2019/3/16 土曜日 マルチディスプレイ時のDisplayPort問題を何とかしてみた 2019/1/12 土曜日 REALFORCEソフトウェアがインストールできない(解決済) 2018/12/6 木曜日 GeForce RTX 2080 Founders Edition を買

    VoQn
    VoQn 2014/10/26
    LLVM本家サイトにあるKaleidoscope実装チュートリアルの和訳だ
  • Google C++スタイルガイド 日本語訳

    Text Drop 翻訳、プログラミング、写真、カメラなどについて書いてます。スタイルガイド/コーディング規約やチートシートなど、ちょっと便利なものを翻訳しています。 TEXTdropでは、C++プログラマーも利用できるパワフルな機能を搭載。C++のコードを書く際に行う手順や避けておきたい工程などを詳しく説明しています。コードスタイルラインの日語版では、日語訳やJ P Yへの換金もサポート。話題性があるオンラインカジノ 日円変換や入金の際のバグにも対応しています。統一性のあるコードを書くためのポイントや規約の種類を参考にする事ができます。

  • Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD

    この記事を書き上げるには、相当長い時間がかかりました。来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって? それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発(TDD)の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい

    Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
    VoQn
    VoQn 2014/08/30
    「Haskellでは(Rubyのような)テストを書く必要がない」としないとQuickCheckとdoctestとHspecとhpcの恩恵受けられないよ
  • クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々

    デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

    クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
    VoQn
    VoQn 2014/08/20
    「恨み」とか「憎しみ」とかの方が継続的に他者を呪うので、「怒り」で済んでるウチに感情精算するほうがマシですね
  • Swift Blog - Apple Developer

    In many cases, your code will not have to change significantly in response to this change. Code that in Swift 2 relied on value types implicitly converting to AnyObject will continue to work as-is in Swift 3 by passing as Any. However, there are places where you will have to change the declared types of variables and methods and get the best experience in Swift 3. Also, if your code is explicitly

    Swift Blog - Apple Developer
    VoQn
    VoQn 2014/07/14
    AppleSwift公式ブログ。やる気に満ちてるわ
  • Structural C++ - d.y.d.

    19:05 08/05/31 私が一番好きなSFと言えば『百万年の船』ですが、 昨日読んで『タウ・ゼロ』が二番目に好きなSFに なりました。最近の感想が大袈裟です。このどうしようもなく取り返しのつかない方向に お話が突っ走っていくっぷりが楽しい。あと、私が感情移入する気になれる主人公ってそうそういない。 いやそれはともかく、 まだこの二冊しか読んだことないのですけど、どうも自分はポール・アンダースンを読み漁るべきっぽいな。 UTPC UTPC というのに参加してました。 みんな解いてるから解けるはず!と思って挑み続けた E が結局解けずじまいでした。 うわーん。K かせめて H に時間使うべきだった。しかし若者勢とロートル勢のバランスが絶妙だ。 → 提出物一式。 13:58 08/05/29 ICFPの ICFP Programming Contest のページが更新されてました。

  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
    VoQn
    VoQn 2014/05/25
    新人じゃなくても、というか職種を違えてもあるある話。「問題の根っこ」を探す気あるか無いか(探し方を知ってるか否か)の問題
  • Using FizzBuzz to Find Developers who Grok Coding

    Musings on technology, development, and the world in general Using FizzBuzz to Find Developers who Grok Coding January 24, 2007 Posted by Imran Ghory in job interviews, Software development. trackback On occasion you meet a developer who seems like a solid programmer. They know their theory, they know their language. They can have a reasonable conversation about programming. But once it comes down

    Using FizzBuzz to Find Developers who Grok Coding
    VoQn
    VoQn 2014/03/27
    FizzBuzz問題の発端。この問題の作者は「こんな程度の問題が解けない奴、数十分かけて解く自称ベテランとかばっかりでうんざりだ」っていう文脈で紹介している
  • Semantic Versioning 2.0.0

    Semantic Versioning 2.0.0 Summary Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Introductio

    VoQn
    VoQn 2014/02/26
    標準化を目指したバージョン番号の付け方の仕様提案
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
    VoQn
    VoQn 2013/10/14
    正直、世の中は「テスト書かなすぎ問題」の方が散見するので、テストは書きすぎる位に啓蒙した方が炎上する現場減ると思っています
  • InfoQ: Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    VoQn
    VoQn 2013/01/03
    読んでみる
  • Getting Real by 37signals

    Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �LN�U �u�M�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →

    Getting Real by 37signals
    VoQn
    VoQn 2012/01/07
    Getting Real の日本語版
  • 俺が勝手に考える正しいMVCの実装。モデルはデータAPI! - はかますたいる!きょろの技的雑記

    最近、一緒にコードを書く人(特にRailsから始めた学生さん)に、 MVC(Model - View - Controller)において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく! 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反

    俺が勝手に考える正しいMVCの実装。モデルはデータAPI! - はかますたいる!きょろの技的雑記
    VoQn
    VoQn 2011/12/25
    今まさに Controller ぶくぶく太らせる麻疹にかかってる段階なので一皮むけたいところ
  • TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組

    @t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前:@irof テストと言うパートナー #TddAdventJp - 日々常々 次:@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が

    TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組
  • JavaScriptの文字列を反転する10の方法とそのパフォーマンス - 風と宇宙とプログラム

    はじめに JavaScriptで文字列を反転する10の方法を(無理矢理?)思いついたので、ちょっと簡単に紹介したい。また、それぞれについて、各ブラウザでパフォーマンスを測定してみたので、その結果も合わせて載せる。 文字列のStringオブジェクトには、部分切り出し(substring, slice)や置換(replace)、連結(concat)など豊富な機能があるのに、反転(reverse)機能はない。Arrayのreverseはあるのに、Stringのreverseがないのはどうしてなのだろうか。 各ブラウザとそのバージョンは以下の通り: Chrome Firefox Opera Safari IE 13.0.782.112 m 6.0 11.50 5.1(7534.50) 8.0.7600.16335 rev01: C言語的発想 空の配列を作って、そこに元の文字列の後ろから1文字つづ入

    JavaScriptの文字列を反転する10の方法とそのパフォーマンス - 風と宇宙とプログラム
    VoQn
    VoQn 2011/08/22
    直観で rev08 の分割統治法が一番速いんじゃないの? って思ったけど,よく考えりゃ木構造で増えるから O(n) の直で直結させた方が速いのか.
  • Press Enter■

    Copyright(c) 2000-2009 ITmedia Inc. 著作権はアイティメディア株式会社またはその記事の筆者に属します。(著作権について) 当サイトに掲載されている記事や画像などの無断転載を禁止します。 「@IT」「@IT自分戦略研究所」「@IT情報マネジメント」「JOB@IT」「@ITハイブックス」「ITmedia」は、アイティメディア株式会社の登録商標です。 当サイトに関するお問い合わせは「@ITへのお問い合わせ」をご覧ください。

    VoQn
    VoQn 2011/04/16
    (悪夢のような)おもしろい読み物だった
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
    VoQn
    VoQn 2010/11/25
    っていうか、本当に上の判断でデザインとエンジニアリングとコーディングを完全に分断しないで欲しいって思うのですよ。3つが摺り合わせてはじめてマトモになるんだから
  • - 継続的インテグレーション

    継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵