Java IDEの使いやすさはIDEがどのようにJavaを知ってるかで決まりがち - きしだのHatena
Java IDEにもいろいろあるけど、それぞれの特性としてIDEがどれだけJavaを知っているかということで決まるということをTwitterに書いたので、ちょっと具体的に書いてみます。 IDEの使いやすさについて、そのIDEがどれだけちゃんと言語を知っているか依存するんだけど、IntelliJ IDEAが一番Java言語を知っていて、NetBeansはJavaのエコシステムを知っていて、EclipseはJavaビジネスを知っている・・・ VS Codeはまとめサイトで見たレベルでJavaを知ってる感— きしだൠ(K8S(Kishidades)) (@kis) 2020年10月30日 ちなみに、全体としてNetBeans推しです。 使い分けとしてはこんなこと書いてます。 Java IDEの選び方 機能いらんけど使いやすくて安定したのがいい→IntelliJ IDEA CE 機能多いのがいいけ
ArrayListじゃなくListを使うという話 - 日々常々
具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の本筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、
Android Javaでフィールドにmプレフィクスをつけるのはやめよう - Islands in the byte stream
Android Javaでは昔からAOSPのcoding style guidelineに則ったスタイルがとられることが多いようです。そのなかで、private fieldに "m" (member) や "s" (static member) などのプレフィクスをつけよ、というものがあります。 AOSP Java Code Style for Contributors | Android Open Source Project これはいわゆるハンガリアン記法の変種で、こういうやつですね。 class Recipe { private String mTitle; private List<String> mSteps; // ... } これについての態度はプロジェクトごとに様々ですが、たとえばクックパッド社のJavaのスタイルガイドでは明確に否定しています。 styleguide/
Scala使用歴5年のプログラマが、この言語とその環境に関する神話を解き明かす | POSTD
(注：2016/1/21、頂いたフィードバックをもとに記事を修正いたしました。) 『 Programming in Scala (Scalaでプログラミング) 』の初版を読み始めた（でも読み終えていない）5年前からJavaの代わりにScalaを使うようになりました。最初はテストの時に使用していましたが、すぐにちょっとしたユーティリティクラスでも使用するようになり、気付いたらプロジェクト全てで使用するようになっていました。 Scalaに対する不満は多く存在しますが、この記事は違います。これは非難するものではなく、むしろ称賛するものです。 Scalaに興味ある開発者や聞いたことがあっても詳しく見たことがない人、「スムーズなプログラミングの妨げになる」と思い使用を先送りしていた人のために書きました。もちろんScalaファンに読んでもらうのも、他の人にも紹介してもらうのも大歓迎です。 この記事は3
脱ビギナー！Androidのnullな話 - クックパッド開発者ブログ
新規広告開発部の松本です。 クックパッドiOS/Androidアプリの広告の開発に携わっています。 Androidアプリ開発の際、皆さんはnullをどのように扱っていますか？また、nullチェックを行うのであれば、どのような基準で行っていますか？私自身まだまだAndroid開発歴が浅いため、特に何か基準がある訳でもなく至る所でif (foo != null)といったnullチェックを行おうとしていました。 これに対し、先日の社内コードレビューでとてもためになるアドバイスをもらいました。私のようなAndroid初心者にとってnullに対する考え方の基礎を作ってくれるレビューだったので、本稿で共有したいと思います。 また、AndroidやJava開発に慣れた方にとっては「今更そんな話か」といった内容かと思いますが、クックパッドでのレビューの一例としてご覧いただければ幸いです。 やりがちなnul
iOSエンジニアが初めてAndroid開発をやってみた第１日目のメモ - その後のその後
当方フリーランスエンジニアですが、iOS専業でやっております。これまで幾度と無く「ちなみにAndroidの方は・・・？」「すいません、できないんです・・・」と肩身の狭い思いをしてきましたが、ついに今日第一歩目を踏み出しました。 ちなみに現在のスペックですが、 iOSアプリ開発歴4年、Android開発歴ゼロ Androidはユーザーとしても経験値ほぼゼロ（先週 Nexus5 購入して WiFi セットアップしただけ） という感じです。 実況中継的に随時追記する形で書いていきたいと思います。iOS からプログラミングの世界に入り、これから Android もやってみたい、という人も今となっては結構多いんじゃないかと思うので、どなたかの第一歩目の参考になれば幸いです。 ※（終了後に追記）あとから読んだ人には何のことかわからないかもしれませんが、本記事は昼ぐらいに出だし（午前中に進めた内容。書籍
getter/setterとはなんだったのか - プログラマーの脳みそ
Javaのgetter/setterのお話。 僕は当時を語るには若すぎるのだけど、過去を振り返って書いてみる。当時を知る人は誤りがあれば指摘してほしいし、情報があればコメントなりトラックバックなりして欲しい。前世紀の話というのは今となっては探すことがなかなか難しくなりつつある。 「privateな変数にpublicなアクセサを定義する」？ - ネットの海の片隅で getter/setterとは何か Javaのオブジェクトにフィールドがあったとして、そのフィールドに値を設定するメソッドがsetter(せったー)、そのフィールドの値を取得するメソッドがgetter(げったー)と呼ばれる。慣習としてsetterはsetXXX(int value)といった様にsetから始まる名前をつけ、引数はひとつ。戻り値はvoid型。getterはgetXXX()といった様にgetから始まる名前をつけ、引数はな
IntelliJ IDEA 13.1のPostfixコード補完 | Post Blog
IDEにおいてコード補完は基本的でどれも同じと考えられがちです。しかしDZoneの記事にもあるようにIntelliJ IDEAはひと味違います。 IntelliJ IDEAコード補完の領域について決して休むことなく進化を続けます。そしてIDEA 13.1ではさらなる生産性をもたらすPostfix code completion機能が搭載されました。 Postfix code completionは書きかけのコードに特定のキーワード(Postfix)を追加することでよくあるコードブロックに整形してくれる機能です。カーソルを戻す頻度を大幅に減らすことができ大幅に開発生産性が向上します。たとえばboolean型の式に”.if”をいうキーワードを追加するとif文に、オブジェクト型の式に”.notnull”と追加すればnullチェックをする文に変えてくれます。 Postfix補完候補はデフォルトでは
一つのメソッドに上から下にずらっと全部書いてしまう現象の考察 - basyura's blog
とある機能を実装するとする。例えば外から Excecute が呼ばれてその結果を返すような場合。多いのが Execute メソッドの中に全部書いてしまって、何 10 行を超えて何回スクロールするんだろうになっているパターン。その際はレビューで以下のようにアドバイスする。 Execute にはシナリオを書いて、中身は別に書くと良いですと。僕の経験的にこの方が良かった、という深い根拠のないものではある。けど、間違った考えとも思わない。自然だろうと。private なメソッドではインスタンス変数を直接扱うのはやめて、public なめそっどから引数で渡したほうがいいとか細かいところもあるけど、そのへんはすっ飛ばしてまずは上記のようにいう。 そんな考えを持っているので、レビュー依頼されたものやコミット済みの資源をなにかの機会で見たときに、上記に反するものを見かけると気になってしまう。 もうちょっと
そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか？ - きしだのはてな
「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？ 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
