艦これのランダム要素が生んだ「物語」の功罪 - 深海の底から
艦これ運ゲー論は飽きた。飽きたんだ。 いい加減このメビウスの輪から抜け出したい。 翻訳記事：ランダム性 | スパ帝国 読み物｜マジック：ザ・ギャザリング cr.hatenablog.com cr.hatenablog.com 「運ゲー」という言葉は広い。そんな言葉の定義論をやってあってるの違っているの言ってもしょうがない。大事なのは、間違いなく侮蔑の意が込められている「運ゲー」という言葉を、何が叫ばせているか、だ。 >>何をしても無駄。できることなんて無い。せいぜい祈るだけ。ああ運ゲー運ゲー。 >>おいちょっと待てそんな言い様はないだろう。 この争いが13年秋から延々と続いている。もう飽きたんだ。そのたびに説明するのもうんざりだ。だからここにまとめておく。 艦これは結果にランダム要素が強く絡むゲームである ランダム要素が生む「物語」 調整に失敗したランダム要素が「運ゲー」と叫ばせる ランダ
"Learn You a Haskell for Great Good!" を翻訳しました - 純粋関数空間
[@nushio](https://twitter.com/#!/nushio)こと村主さんと Learn You a Haskell for Great Good! を翻訳しました。 「すごいHaskellたのしく学ぼう！」というタイトルで、 5月22日、オーム社様より発売予定です！ 詳しい情報は http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06885-0 こちら。 入門書としての出来の良さに惚れ込んで原著者の Miran Lipovača さんに 翻訳したい旨を伝えたのが発端でした。ちょうど去年の夏頃でしたか。 そうこうしているうちに、オーム社の鹿野さんから出版のお話を頂いて、 トントン拍子で進んで行きました。 翻訳作業の方はトントン拍子とはいかず、 関係者の皆様にはご迷惑をお掛けしました。 ともあれ、完成しました。5
書評「型システム入門」 - 純粋関数空間
追記：Amazonのリンクを張っていますが、オーム社のサイト http://estore.ohmsha.co.jp/titles/978427406911P からも購入できます。 AmazonのKindle版はまだ出ていないようですが、 こちらからは今現在でDRMなしのPDFも購入できます。 Kindle版リリースの際にも、 フローレイアウトになる予定はないそうですので、 Amazonにこだわりがあるのでなければ、 電子版で読みたいという方は、こちらから購入されるのが良いかと思います。 あらかじめお断りしておきますと、 この記事は書評ではなく、宣伝です。 数年前に原著を読んだ時から、 本書は私の中では間違いなく良書ということになっておりますので、 私がいまさら内容の善し悪しを語ることには、 はじめから意味がないと思っております。 なのでここでは、この本の魅力、読んで欲しい人、どういう風に読
Qiitaで自分の古い記事に警告をつけて回った、Rubyで。 - Qiita
書きやすいのでホイホイQiitaに色々記事を書いてるわけですが、たまにやたら古い記事をストックされることがあります。 古いだけで今でも通用する内容なら良いんだけど、ライブラリのバージョンとか変わりすぎてて、そのままでは全く動かない記事もある。 動かないとはっきりわかっている記事がストックされたら、手動で警告をいれたりもしています。 ただ、毎度警告を書くわけにもいかない。とりあえず古い記事には これ古いのよ と適当につけてみました。 この記事用のリポジトリ： sawanoboly/qiita-articles-best-before Rakeで全部の記事に警告をつける またRakeでベタ書きか。はい。 最終更新日を基準に、365日くらい経過している記事には先頭に固定の文字列を入れることにした。 # coding: utf-8 require 'qiita' require 'formatad
Arduinoの内部分裂について
仲が良かった頃のArduinoチーム （写真の出典：arduino.cc） ご存知の方も多いと思いますが、Arduinoチームが内部分裂してもめています。おおざっぱに言うと、米国のArduino LLCという会社と、イタリアのArduino SRLという会社が、それぞれ「我こそは正当なArduinoだ」「お前は偽物だ」と言って争っているのです。Arduino LLCは、元々のArduinoの開発者5人が設立した会社です。Arduino SRLは、その5人のうちのGianluca Martino氏が長く経営しArduinoの製造と全世界への販売を担ってきた会社です。現時点では、合計4件またはそれ以上の訴訟または異議申立てが係争中です。 じゃあ、どっちが正しいArduinoなのか。海外のブログとか掲示板とかでは、わりとArduino LLCの肩を持つ意見が多くて、Arduino SRLに対する
SEO業者に35万円払ったが、最悪な結果となったのでブログをはじめました。本当にありがとうございました。
タイトルの通りですが、僕は昨年、とある業者に350,000円（正確には、税込378,000円）払って、SEO対策を依頼しました。 そして、その結果は、マジFUCKER！って感じでした。 施策を受けた対象のサイトは、このサイトではありませんが、やはり35万円はすぐに立ち直れる金額ではなかったので、その時の詳しい経緯から現在、そしてこれからについて書いてみようと思います。 今回、具体的な業者の名前は伏せておきます。（なんか変なことされると怖いので） ただ、大手どころです。 大手だから大丈夫かな、と思った自分が情けないです。 大手だから、「より上手く」ごまかせるんですね。 これからSEOを外にお願いしようと思っている方は、もう一度考え直す必要があるかもしれませんよ。 SEOの裏技とは？ウェブサイトから情報発信する方にとっては、SEO（検索エンジン最適化）は、誰しもが興味のあるところかと思います。
- データベースの進化的設計
データベースの進化的設計 Martin Fowler Pramod Sadalage 原文(Evolutionaly Database Design) ここ何年かで私たちはアプリケーションの開発に即してデータベースの設計を進化させることを可能にする技法を編み出した。このことはアジャイルメソッドにとって非常に重要である。この技法は継続的インテグレーション及び自動化されたリファクタリングをデータベースの開発に適用し、かつDBAとアプリケーション開発者が密接に協力することによって成り立つ。この技法は開発中のシステムや既に開発されたシステムに対しても機能する。 変化に対応する 制限事項 プラクティス集 DBAは開発者と密接に協力し合う 全員が自分のデータベースインスタンスを保有する 開発者は共有マスターに頻繁に結合する スキーマとテストデータから成るデータベース すべての変更でデータベースのリファ
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
社内勉強会はヤメだ。自主的はいらん、全員技術発表だ！ - @ledsun blog
社内勉強会について僕にも思うところがある*1。 社内勉強会をやらない理由 - 勘と経験と読経 社内内弁慶を社外勉強会に参加させる方法: ソフトウェアさかば 最初に言っておくと弊社は20人くらいしか居ないし、受託開発と派遣が半々くらいのSIerだ。 id:kent4989 の会社とはだいぶ状況が違う。 社内勉強会はやらない 結論から言うと社内勉強会はやっていない。やらない理由は発表者のコストが高くてメリットが少ない。 勉強会のつらさ IT系の勉強会のノリだと テーマに対して興味のある人が少なく参加者が少ない 最新ネタは業務と離れすぎていて、継続する努力がハイコスト過ぎる 研修のつらさ 教育を重視して基礎的な内容をやると 基礎的な内容だと教える側が刺激が足りなくて飽きる 教える側が教えるほどは理解していないので、事前準備がハイコスト過ぎる そんなわけで社内勉強会をやるのはやめました*2。 技術
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリを作る際に理解しておいて欲しい「Model」という役割について説明します。わりと意識していないケースがあるので、チェックしてみてください。Read less
OOじゃないDDDについて - うさぎ組
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
アジャイル設計と5つの原則 - かまずにまるのみ。
アジャイルソフトウェア開発の奥義 第2部「アジャイル設計」の自分用まとめ。 アジャイル設計 アジャイルな設計 「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。 悪い設計 第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。 硬さ （設計変更が難しい） 脆さ （設計が壊れやすい） 移植性のなさ （再利用が難しい） 扱いにくさ（正しい設計をするのが困難なソフトウェア、面倒な開発環境） 不必要な複雑さ（"後で必要になるかもしれない"と考えて先行実装したコード） 不必要な繰り返し （コピペ） 不透明さ （目的や意図がわかりにくい） 原則 システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。 ただし無条件で原則に従うと「不必要な複雑さ」を招
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler's Bliki in Japanese - FrontPage
IOS/Androidアプリの３つの大事な設計方針
知らないと損するアプリ開発におけるStateMachineの活用法（full版）
ディズニーアニメの12の基本原則をグラフィカルに紹介するGIF画像
ウェブ初心者も安心して作成できる、無料HTMLテンプレート素材24個まとめ - PhotoshopVIP
TechCrunch | Startup and Technology News
Partial Mocks · Issue #61 · phpspec/prophecy