イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパ…
イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパ…
このエントリでは、Yegor Bugayenkoによる記事、Getters/Setters. Evil. Period.を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 2003年にAllen Holubが書いたWhy getter and setter methods are evilという有名な記事に端を発する古い議論がある。それは、getter/setterはアンチパターンで避けるべきものなのか、 もしくはオブジェクト指向プログラミングに必須なものなのかというもの。 この議論に少しだけ私の意見を加えたいと思う。 上記記事の要旨はこうだ。 getterやsetterはひどい慣習で、これらを使うやつらはゆるせん。誤解の無いようもう一度言うが、 私はget
DeNAさんとGoodpatchさんが共催するセミナー「UI Crunch#8」に参加してきました。 毎回応募者が殺到し、倍率が何倍にもなる人気セミナーですが、今回もご多分に漏れず、120人枠に733人もの申し込みがあり、当選確率が6倍にもなっていました。 今回私はUX MILKの突撃レポーターとして参加させてもらうことができましたので、メディア席の最前列よりイベントの様子をレポートさせていただきたいと思います。 プレゼンテーション 株式会社サイバーエージェント｜佐藤洋介さん テクニカルクリエイターが担う、サービス開発のUIモックの現場 〜サイバーエージェント流〜 サイバーエージェントでは、ワンストップでUI/UXを考慮し実装まで落とし込めるような人を「テクニカルクリエイター」と呼び、「テクニカルクリエイター」がどうして生まれたのかその背景と実際にどのようなお仕事をされているのかお話が聞け
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
AutoLayoutを使ってセル上を左にスワイプすると、セルの右側がオープンするUITableViewCellを実装してみます。セルの削除のときによく出てくるあれを自分で実装する感じです。 AutoLayoutやstoryboardにある程度知識がある方を前提としていますので、適宜不足している情報は補って実装してみてください＞＜ 準備編 まずは、通常通りにstoryboardでUITableViewを実装します。 次に、スワイプした時にわかるようにセルの背景色を変えておきます。 これで準備完了です。スワイプできるセルを実装していきます。 TableViewを貼り付けているViewControllerは以下のようになっています。普通です。 import UIKit class ViewController: UIViewController, UITableViewDataSource {
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
みなさん本を読んでますか？ Kawaz Advent Calendarの8日目を担当させて頂く@giginetです。よろしくお願いします。 皆様、本は読んでますか？ 僕は今年Kindleを買ってからかなり読書量が増えました。 もちろんゲーム関係の本も読んでいたのですが、ぜひ作っている仲間内でこの価値観や知識は共有しておきたいなあ、という良著に多く出会いました。 実はゲーム開発に関係する本って、世の中にたくさん出ています。 ミーティングなどでいちいち紹介するのも面倒になってきたので、この機会に是非読んで欲しい本を一挙紹介します。買いましょう。 この記事では ゲームを作ってみたいと考えている方が広く読むべき本を紹介します 役職に関係なく読める本を選んでいます。そのため、例えばプログラミングの技術書など、前提知識が必要な本は意図的に抜いてあります オススメ度は個人の感想です。また、僕の読後感だけ
English UIAppearance の proxy メソッドから見た目を変更して、即時全画面に適用する方法を調べていて、UISS という iOS で JSON 形式の Stylesheet を扱うライブラリにその答えがあったので、メモです。 UISS#refreshViews - (void)refreshViews { [[NSNotificationCenter defaultCenter] postNotificationName:UISSWillRefreshViewsNotification object:self]; for (UIWindow *window in [UIApplication sharedApplication].windows) { for (UIView *view in window.subviews) { [view removeFromSup
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1. はじめに 皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル1のプログラマ2です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。 でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 実践的なパターン 永続化のパターン Jeremy Miller 目次 データベースへのオブジェクトのマッピング Active Record Data Mapper Repository の使用 Identity Map Lazy Loading と Eager Loading Virtual Proxy パターン 次のステップ データ アクセスは、開発者の間では一般的なテーマです。確かに、特定のデータ アクセス テクノロジと永続化のフレームワークに関する意見は多数ありますが、各自のプロジェクトでこれらのツールを使用する最善の方法は何でしょうか。プロジェクトに対して正しいツールを選択するには、どのような基準を使
(Last Updated On: 2019年5月29日)少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。 契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。 契約プログラミングとは 契約プログラミングは比較的新しい設計思想で、サポートしている言語にはEffile、D、Clojure、Valaなどがあります。最近作られた言語の多くが契約プログラミングをサポートする機能を持っています。C++、C#やJavaなどでも契約プログラミングをサポートするライブラリが利用できます。契約プログラミングをサポートする言語やライブラリを利用しない場合でも、契約プログラミングの概念を適用すると安全かつ効率が良い開発の手助けになります。 Wikipdiaの
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
後半のセッションでは、「What the system is（共通性や可変性を分析する）」を説明しつつも、「What the system does」とは別のものとして切り分けることはできないという主張から、 DDD とリーンアーキテクチャとの比較、そしてパターンに関する議論が展開されました。 @remore が前半部分をまとめてくださっていまして、そこで出て来るいくつかの用語（Form, Structure, What the system is, What the system does）を前提として私のできる範囲で行いました。 なお当日のCoplien氏によるセッション内容は、許可を得た上でYouTubeにアップロードされていますので、より深くご覧になりたい方はこちらも併せてご参照下さい。 DCI Tokyo 1 - Lean Architecture by James Coplie
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
