"ふつうのJavaコーディング"を話しました - 日々常々
2017/5/20にあったJJUG CCC 2017 Springで登壇させていただきました。 8回目の参加です。 毎回パワーアップしているなーと言うのは前回のブログでも書きましたが、今回は目に見えて参加人数が増えたんだなーと体感しました。 入れないセッションもありましたし、懇親会も超満員でした。運営の皆様に本当に感謝です。 今後も楽しみにしています。 話したもの ごくふつうの話、のつもり。ふつうって一体なんだとか思わなくはないですが、ただの枕詞なので意味はないです。 結局のところ九段に集約されるんですが、強い意思を持つには色々必要で、まあそんな感じです。 「coming soon」となっている61スライド目 先日（6/24）発売のWEB+DB PRESS Vol.99 で書いてます。 WEB+DB PRESS Vol.99 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元
あっと驚かせるJavaプログラミング(をやめよう） - Qiita
はじめに 驚き最小の原則（法則）という言葉があります。 Wikipediaの記事を引用すると http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87 ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 要するに、使うときに「おやっ？」という驚きが少ないほうが良いプログラムであるといえます[1]。 [1]: どっちが驚きが少ないか迷う場面もかなり多いですが・・・ この記事では敢えて驚きの多いプログラムの書き方を紹介します。驚きの多いプログラムを読むとどんな気分になるか、
その事例だとコメントは不要だと思います - erukitiのmiscなやつ
「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさのテクノロジーは今か無しか および 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（補足編） - 土屋つかさのテクノロジーは今か無しかで、計算式の意図を説明するためにコメントを書こうぜという主張が書かれてますが、この内容だと全く賛同できませんね。別にコメントを全否定するわけではありませんが、この主張の例だと不適切です。 //フェードインが未完了の場合 if (alpha < 1.0f){ //処理A } 元記事の主張は、alpha < 1.0f という計算式はコメントなしでは本来の意味であるフェードインが未完了の場合、というものがさっぱりわからないということでした。つまり意味情報の欠落を問題にしています。 const isFadeinCompleted = () => alpha
Arrays.asList() は単なる配列のラッパを返すだけなので、要素の追加も削除もできません - A Memorandum
いつまでたっても間違いが無くなりません。 以下のようにListの初期化で多用するArrays.asList()。 List<String> stooges = Arrays.asList("Larry", "Moe", "Curly"); Arrays.asList() が返すインスタンスは、java.util.Arrays$ArrayList であって、java.util.ArrayList ではありません。 Arrays.asList() の実装は以下のようになっています。 public class Arrays { public static <T> List<T> asList(T... a) { return new ArrayList<>(a); } } 分かりにくいですが、ここでインスタンス化される ArrayList は Arrays の内部クラスで以下のクラスです。 pu
失敗を表現する手法としてNullObjectパターンが不適切でEitherが適切だと思う理由 - Qiita
真面目な気分出して書いていたらすごい長くて堅苦しくてもったいぶった感じになってしまった... この記事の9割は壮大な前置きですw なにこれ 失敗の表現としてNullObjectパターン（以下楽なので勝手にNOPとします）を使うべきか議論をした際に論理立てて話せなかったので、 持論整理をしてついでにこの場を借りて晒してみようと言う記事です。 全ての状況において必ずEitherだ！と言うよりは、議論になったら僕はこう考えてますって言うためのポエムです。 DDD的な考えも少し この記事は実装都合のみに閉じていますが、DDD的な観点からも考えてみたことがあるのでこんな記事も書いてみました。 先に結論 前置きではない1割の部分だけ先出します。 それで「あ、そうか」とか「は？」とか思える人は以下の長大な前置きは不要ですw NOPは成功と失敗を区別しようとすると破綻する、けど区別したい事が珍しくない。
デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。 独立したコンサルタントでトレーナであるKevlin Henney氏が、ヨーロッパテストカンファレンス 2017において、基調講演「やり方の間違い」を行った。この基調講演で、デッドコードが実行されたために、ある企業が何億ドルもの損害を被ったことを発表した。 InfoQは、このカンファレンスをQ&A、要約、記事で扱う。 ソフトウェアの失敗は、個人的に不便だったり、迷惑だったりするが、経済的、または、社会的に重大な影響を与えることもある。Henney氏は、小さな不具合のせいで、何百万ドルもの損害を出した例をいくつか
外国人が語る：英語でクラスやメソッド等の名付け方 - Qiita
アメリカ人です。 Hello 👋 この記事の目的 多くの日本人は自分の英語力には自信がないではないでしょうか。残念ながら「英語がわからん」、「英語が全然できない」という声をしょっちゅう聞いています。でも、今まで英語ができて意味がちゃんと伝わる何人かの日本人に会ったがあります。完璧な英語ではないけど(外国人も英語でミスる時もある...)、がんばって話そうとするので充分仕事ができる人たち。そういうがんばる姿勢はオープンソースのプログラムや英語圏のプログラムに手を出すためには一番大事なことだと思います（外国人側もすごく助かります）。日本の文化では「私はできる！」と自慢することは少ない中、この記事を通して、流暢に話せなくても自分のプログラミングの命名の仕方にはちょっとだけでも自信を持たせたいなと思います。完璧じゃなくていいです。Let's go! 合わせて読んでいただきたい 【日本人エンジニア必
私的アンリーダブルコード―他人を発狂させるための 9 のテクニック
コードはたいてい一度しか書かれませんが、何度も何人も読むことになります。 普段何気なく書いているコードが他人の時間と精神を削っているかもしれません。 そんなわけで、個人的に辛いなと思うことを 9 つ挙げてみました。共感してもらえるものもいくつかあるんじゃないかと思います。 実体にそぐわない変数名 見分けの付かない配列とハッシュの変数名 呼び出し元で true/false を指定するだけの引数 暗黙の実行順序 [] メソッドの定義・Array の継承 ハッシュの乱用 密結合した mixin 過剰な nil guard 条件によって異なる返り値の型 推薦図書 静的型付き言語を使うことで解消される問題もありますが、その選択肢はひとまずなしということで。 Ruby 前提になっていますが、他の言語にも言えることも多いと思います。 実体にそぐわない変数名 例えば Vehicle というクラスが定義され
ライブラリのバージョニングのしかた - Islands in the byte stream
セマンティックバージョニングは守るとして、だいたいこんなポリシーでやってます。 0.0.1 - proof of concept / minimum viable product 0.1.0 - とりあえずリリースしてプロダクションに組み込んでみる 1.0.0 - プロダクションに組み込んだ 2.0.0 - セマンティックバージョニングに従うので、メジャーバージョンアップは機能ではなく単にAPI互換性を失うという印 あとは、alpha, beta, rcなどを接尾詞としてつけることもあります。 *-alpha - 開発中 *-beta - 安定してきた *-rc - release candidate. プロダクションに組み込んでもOK
What's "tools:context" in Android layout files?
Starting with a recent new version of ADT, I've noticed this new attribute on the layout XML files, for example: <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" tools:context=".MainActivity" /> What is "tools:context" used for
Rubyによるデザインパターン5原則 - Qiita
概要 改めて基本を学ぶ。 Rubyによるデザインパターン第1章。 デザインパターンとは プログラミングにおいて繰り返し現れる問題に対する、適切解のパターン。 無駄無く設計されたオブジェクト指向プログラムの実現をサポート。 パターンとしてカタログ化されていることで 車輪の再発明を防ぐ デザインパターンの根底にある5つの考え 変わるものを変わらないものから分離する プログラムはインターフェイスに対して行う（実装に対して行わない） 継承より集約 委譲、委譲、委譲 必要になるまで作るな（YAGNI） 変わるものを変わらないものから分離する ソフトウェアの仕様には必ず変更が加わるもの。 変わるものと変わらないものを分離しておくことで、 「仕様の変更」に対して「システムの変更」を出来る限り局所的にする。 プログラムはインターフェイスに対して行う（実装に対して行わない） 可能な限り「一般的・抽象的なもの
プログラミング勉強を加速させる7つの習慣 - Qiita
※ 本記事は自分が運営するブログに転載しています 株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2016』16日目の記事です。 はじめに 私は学生時代は情報工学の専攻でもなければ、趣味でプログラミングをやっていたわけでもなく、 社会人になってWebエンジニアとして初めてまともにプログラミングを勉強し始めました。 入社するまでに独学で勉強の真似事をしてはいましたが、そもそもどうやって勉強していいのか全然わからず、 本を読んで写経をして何故だか理由はよくわからないが動作してしまうミニブログを眺めては、ため息を付いて挫折を繰り返しておりました。 そんな初心者だった自分が、Webエンジニアとして食べていくために本気で努力して身につけたノウハウを、 「プログラミング勉強を加
【新人教育 資料】第1章 UMLまでの道 〜オブジェクト指向編〜 - Qiita
箸休めには以下をどうぞ 【新人教育 資料】ハードウェア編 では、今回もはじめていきましょう！ オブジェクト指向 オブジェクトを日本語に訳すと「モノ」、「対象」となります。 プログラムを勉強していくとオブジェクトと言葉をよく聞きますが、一旦「モノ」と考えるとわかりやすいかもしれません。 では、現実世界で物と言われるものはなんでしょう？ ※このポストをしている人は自分の仕事机からの景色を使って説明しようとしています パソコン モニター 時計 椅子 人 これらは全て、「モノ」ですね。知覚的に、言葉を聞いただけで、それはどういったものが理解することが出来ます。 このような「モノ」は言葉として表現すると理解し、大体一般的に共通認識出来るものがオブジェクトだと考えてください。 オブジェクト指向とは、さらに「モノ」に加え「こと（振る舞い）」をするものもオブジェクトで表現しようというのがオブジェクト指向で
トラブルシューティングのすゝめ - Qiita
この記事は、Life is Tech ! Advent Calendar 2016 の14日目の記事です。 はじめに はじめまして、Life is Tech ! ではMinecraftプログラミングコースのコースリーダーの他、黒ポロメンターとして活動しているラルフというものです。 黒ポロメンターとは: ス○バの黒エプロンのLife is Tech ! 版 技術力が長けていたり、Life is Tech ! に対して大きなコミットをした人などが認定される仕組み。現在10名ほどが認定を受けている。 黒ポロメンターに必要な力 技術力はもちろん、教える力など、必要な要素は多々ありますが、個人的に重要視しているのは エラーの解決能力 です。 メンバーやメンターなどから来た質問から如何に正確に、素早く原因を探り出し、解決方法を提示できるかという力が重要です。 今回は、エラー解決までにどんなフローをたど
Groovy 2.3.0-betaが出たのでtraitを触ってみたメモ - uehaj's blog
Groovy 2.3.0-beta-1とbeta-2が出たので新機能traitをかるく触ってみました。 注意! 以下は現時点で2.3.0-beta-1と2の振舞いとドキュメントを調べた限りの情報です。正式リリースに向けて変更される可能性があります。 関連記事 Introduce Groovy 2.3 trait Groovy 2.3のtraitをもうちょっと調べてみるついでにScalaのtraitを理解する - uehaj's blog traitの概要と目的 Groovyのtraitは、一言で言って「実装の多重継承」を可能とする仕組みです。詳しくはこちらの本家ドキュメント(英語)をどうぞ。 GroovyおよびJava 7までのJavaでは、インターフェースは多重継承することができましたが、クラスは多重継承できませんでした。実装、すなわちメソッド本体の定義や、非public static
15日目：トレンドなトレイト - Kotlin Advent Calendar 2012 (全部俺)
アドベントカレンダー15日目の今日はトレイトという機能に注目したいと思います。トレイトとは実装を持ったインタフェースのようなものです。これはJVM言語のScala（まさにトレイトという名前の機能）や、Java SE 8（予定）にもある機能です。インタフェースが実装を持つとことで便利なこともありますが、問題もあるのではないかと心配になりますね。そこらへんを見て行きましょう。 抽象クラス トレイトの話題の前に抽象クラスを紹介します。抽象クラス、Javaプログラマならご存知ですね。抽象関数を持つクラスのことを抽象クラスと言い、そのクラスはインスタンス化できません。サブクラスを作成するために使用します。抽象関数とは実装を持たず、関数シグネチャのみを宣言した関数です。具体的な実装はサブクラスで定義します。ポリモーフィズム（多態性）を実現するための重要な仕組みです。 抽象クラスの概念のおさらいはここま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google、教育向けビジュアルプログラミング言語「Blockly」、Android/iOS向けに提供開始 
【保存版】1日に3回プログラミング勉強法を聞かれるのでまとめてみる | ロボット・IT雑食日記
Groovyで非整数刻みの数列を作る - Qiita
一人トランザクション技術 - Qiita Advent Calendar 2016 - Qiita
