オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
null安全を誤解している人達へのメッセージ - Qiita
null安全を誤解している人達へのメッセージ 先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃ
C#コーディング規約の個人的なまとめ
コーディング規約は非常に色々なものが提案されているが、その色々なものを見て来た中で、かなり自分勝手な方向でまとめてみる。 はじめに コーディング規約というのは、さまざまな団体で独自に定められており、時にはそれが競合することもあろうかと思う。特にC++のプレフィックス関連が顕著だと思う。それに比べて、C#は割りと落ち着いたコーディング規約が根付いているのか、私の短いプログラミング人生の中で、そこまで読みにくいと思ったコードを見たことがない。これは、C#の言語構造やVisualStudioの自動整形も関係しているのかもしれないが。 というわけで、厳格なコーディング規約を設けずとも、それなりに読めてしまうC#でも、やはり規約を定めて、より読みやすく、統一性を持たせたコードを生産することは、非常に有意義なことだと考える。 代表的な記法 C#の命名規約についてを参考にしてほしい。一部を抜粋しておく。
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
技術的負債とどうやって戦うか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで
Android アプリのコードを綺麗に保つためのコードレビューのチェックリスト4項目 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Android アプリの開発で起きがちな問題を予防するためのコードレビューのチェックリストです。 チェックリストの方針 極力数少ない項目で多くの問題を防げること。 要は「最低限これを守ってくれるとまずまず OK だと思います」くらいのものです。 項目が少ないので重要な事柄に集中できますしレビュワの経験が少ない人もとっかかりやすいと思います。 全体的に、開発経験がそこまで豊富ではない方向けのチェックリストになっていると思います。 チェックリスト 全4項目です。 1. なるべく Activity にフィールドでフラグを持たせないこと そうす
ifの条件が2つ以上だと頭がパンクする
if(param==0 ＆＆ 判定(param2) || !param3){ //したいこと } みたいに3つぐらい条件がある場合、頭がパンクしそうになる。 この時こう考えている。 1:したいことをする条件は 2:paramが0 3：かつ 4：判定関数でparam2の条件を返して、true 5：またはparam3がfalseのときがtrueだから 6：trueだとだめなんだよね。falseが正しいんだ。でもfalseは偽なのに正？ 8:あれ、何したいんだっけ。まぁいいや、とりあえず実行してエラーなら直そう。 7：実行。 8:あれ？なんか違う。何がおかしいんだ 1へ戻る。 これを3,4回繰り返してウアアアアアアアアアアアってなってしまう。 誰か助けて
Android Studioの超高速コーディングを支える技術（テクニック） - Qiita
追記（宣伝）： 今年の夏から大阪でフルリモートなフリーランスAndroid/iOS/Webエンジニアをやっています。ただいま週1-2または請負のお仕事お待ちしております・・！ 画面見た人から（Enterやらショートカットやら連打で）何やってんだかわからないって言われることがたまにあるので、Android Studioでどうやってコーディングしているのかを書きました。 単なるショートカット集ではなく、あえてエラーのある状態を作るなどのテクニック集です。 なおMacかつAndroid Studio標準のキーバインドを前提としているので違う方は読み替えてください。（もちろんIntelliJでも同じことができるはずです・・！） 原則 考えるな、感じろ。: Alt+Enterや補完キーなどを押した次の状態を頭の中に思い浮かべながらに対して反射的に操作すると、超高速コーディングできる エラーだろうが汚
プログラミングでよく使う英単語のまとめ【随時更新】
対になる言葉 comment out / uncomment コメントにする、コメントを解除する。 comment out は into a comment の意味。 comment だけならコメントする、評するの意味になる。 add / remove 追加する、削除する。 リストなどに値を入れる場合などにも使われる。 特に、末尾に追加する場合は append、先頭に追加する場合は prepend を使う。 Add A to B で、A を B に加える。 Remove A from B で、B から A を取り除く。 start / stop 開始する、止める。名詞だと開始、停止。 静止状態から動き出す感じが start。 途中からでも使える。 バーコードや通信の符号で StartCode / StopCode という使い方をする。 begin / end 始める、終わる。 最初の一歩を
103139
エミュレータを作ってみたいなぁという漠然とした思いがずっとあったので、ファミコンのエミュレータを書いている。スクリーンショットにあるような表示はできる。 ファミコンにした理由 エミュレータは作りたいが、よく知らない機械のエミュレータを作ってもつまらないので、多少は親しんだファミコンにした。 一番印象深いゲーム機はスーパーファミコンだが、スーパーがついてないほうが簡単かな、と思ってファミコンにした。 買ったもの カートリッジからROMイメージを吸い出すために、吸い出し機をAmazonで購入した。 GAMEBANK-web.comオリジナル「FCダンパー」 / ファミコン ファミリーコンピュータ Famicom Kazzo DUMPER レトロゲーム 吸い出しツール [0217] 出版社/メーカー: GAMEBANK-web.comメディア: エレクトロニクスこの商品を含むブログを見る ゲーム
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
分割されたv4 Support Librariesのリスト - EDIT MODE
1. 概要 Android Support Library のバージョン 24.2.0 がリリースされましたが、このバージョンから v4 Support Library を分割されたものが使えるようになりました。 参考：Support Library Features 以下の Library 群として提供されています。 support-compat support-core-ui support-core-utils support-fragment support-media-compat とはいえ、Support Library 群で最も大きかった v4 なので、どのライブラリに何があるのか分からないのが不便だったので、調べてみました。 2. パッケージ構成 support-compat android.support.v4.accessibilityservice android.s
Weak Referencesから学ぶJavaにおけるオブジェクトの4種類の参照 - リア充爆発日記
各種ドキュメント等を見ていたらWeakReferenceクラスなるものを見つけた。 http://developer.android.com/reference/java/lang/ref/WeakReference.html これを読んでも英語力のせいか何を言っているのかよくわからなかったけど、メモリ消費の話に繋がることはわかったので、Androidアプリには重要なはずや！と思ってもっと調べて見ることにした。 ちなみに現時点での総Java歴1年そこそこの僕のJavaの「参照」の認識としては"GC絡みで出てくる話で、そのオブジェクトが別のどのオブジェクトからも参照されなくなったらGCの対象になる" といった程度。 信頼と実績のSOを経てたどり着いたのはこちら。 Understanding Weak References するとJavaの「参照」は4種類もあるらしい。。。知らんかった。こうい
忙しい人の為のDependency Injection(依存性注入)の概念 - Qiita
はじめに 依存性の注入って稀に良く聞くけど何それよく分からん怖いって人(私)向けに書きました。 DIライブラリの使い方からDIを学ぼうとすると困難だったので、まずはDIとは？についてまとめています。 DIを行う組み立て役の係Assemblerが居ること、依存性という単語ではなく依存オブジェクトと念頭に置いとくと理解しやすいです。 Dependency Injection(依存オブジェクト注入)とは DIとは、Controllerが使用したい依存オブジェクトを第三者オブジェクトが生成/代入する概念のこと。 依存オブジェクトを生成/代入をする第三者オブジェクトAssemblerを導入する必要がある。 前提としてClassの公開済みの振る舞いとしてProtocol/Interface相当で定義する必要がある。 Protocol/Interfaceを使用しないスタイルでコーディングしているならば、
IT英単語の発音とスペル - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「IT英単語」と題しているが、主にWeb開発に関する英単語を集めた。 これらの英単語は、書籍やWebページなどのテキストコンテンツのみから学習していると、正しい発音を知らないまま日本人らしい誤った発音で記憶してしまうことがある。 なお、単語の追加を提案してもらえる場合は、ページ下部のコメント欄の直前にある「編集リクエスト」ボタンから行って欲しい。 正しい発音をするべきかどうかの議論 そもそも英単語を正しく発音するべきかどうかの議論は多い。1 不要論 「日本人なんだから通じれば発音なんてどうでもいい」という意見があるが、明らかに誤った発音
Excelで佐々木希を描く with python - Qiita
#【環境】 windows8.1 Excel 2013 python2.7 opencv3 #【概要】 佐々木希の写真から色の情報を取得して、Excelのセルに塗りつぶします。 #【フォルダ構成】 |---sasaki_excel |---sasaki_excel.py |---sasaki_nozomi.jpg（佐々木希の画像） |---sasaki_nozomi.xlsx（描画用のエクセル） こちらの画像を使用しました。 #【プログラム】 # -*- coding:utf-8 -*- import cv2 from openpyxl import load_workbook from openpyxl.styles import PatternFill # 画像読み込み image = cv2.imread("sasaki_nozomi.jpg") # エクセルファイル読み込み wb
Application Contextは使ってはいけない - ちりもつ on ytRino
タイトルは誇張です。 みんな大好きpotatotipsという勉強会で以下のようなトークがあったようです。(現場には行っていません) 曰く「ActivityContextで何千回もやったら数回リークが検出された。 なるべくApplicationContextを使おう」とのことらしいですが、間違いなく死人が出る(誇張)と思いますのでご注意ください。 (追記20160527: 修正されたようです なんかすみません) speakerdeck.com 結論 Application Contextは使わないでください。(誇張) (実際は使うときは使う) なぜApplication Contextなのか Application Context使おうぜ!という根拠の記事としてこちらのフェンリルのDeveloper's Blogの [追記あり] Android 開発で気をつけたいこと 〜変数名と Conte
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入門者向け「Delphi」「C++Builder」の有償販売が終了、無期限の無償版として公開
コードを書く際の指針として見返すサイトまとめ - Qiita
メモリリークに関するウワサの今昔
