「演算子」を含む日記 RSS

はてなキーワード: 演算子とは

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-05-06

Perlは終わった完全にオワコン

perlは終わった。もうずいぶん前から終わってたけど話題にも上がらないってことは完全に終わってる。

Githubトレンドを見てもperlなんて出てくる日の方が少ない。

結局Perlみたいにいろんな書き方ができるような言語はお呼びじゃねーってことだろう

Go/Pythonみたいな言語がもてはやされるのはそのためだろう

ライブラリ充実度に至ってはpython圧勝

Web開発ならRailsがあるRuby

どこでも動かせる意味ならGolangが最強だろう

Perl6については意味からない演算子増えて、さらに読みにくくなった

うPython, Rubyに追いつくこともできないだろう何よりリリースが遅すぎたもうPerlが入る余地はない

バイバイPerl(´;ω;`)ノシ

2017-04-22

http://anond.hatelabo.jp/20170422015216

言いたい事は判るけど言語スキーとしてはどれも書いててそれなりに面白さはあると思う。

判ってくると楽しい、みたいなやつ。

まぁ仰る通り保守性・可読性には一切寄与しないし「俺つえー」的な自尊心満たすだけかも知れないけどw

あと言語の多機能さとか演算子オーバーロードモンキーパッチ批判するなら Scala も入れといて欲しいかな。

あれも関数型ってだけでなんかありがたがられてる感あるけどそういう意味じゃなかなか酷い言語

C++/Perl/Rubyゴミ

分かったのは言語の多機能さというのは、一点水準さえ満たしていれば、それ以上足しても生産性寄与しないという事

自分しか使わない、最初書くときに限れば書きやすいと思うこともあるが、それ以上に保守性を落とす

ライブラリを利用したり他人コードを読む機会の方が多い昨今マイナス要素でしかない

perlスローガンだかに "There's More Than One Way To Do It." というのがあるらしいが、読む側からするとたまったもんじゃない

演算子オーバーロードされてるかも?モンキーパッチされてないかな?等々あれこれ想定しなきゃいけないのが苦痛しかない

スラムダンク流川が沢北を抜いたのも

パス選択肢を見せた事で沢北が集中できなくなってしまたか

それほど選択肢が多いということはストレスになる

Rubyゴミ

DSL(笑)が良いと思ってるのは最初だけで、最終的に負債しかならない糞コード

統計機械学習系のライブラリが皆無で先細りのイメージしかいかRailsと一緒に心中ください

Perlゴミ

リスト評価スカラー評価とか意味わかんねーくくりもtie変数アイディアは糞中の糞

Perl6にいたってはわけわかんねー演算子オンパレードで悪いところをさらに悪くした感じ

C++ゴミ

テンプレートマクロboostも何もかもダメ意味不明

オーバーロードされまくりコードなんてどっから読んでいいかわかんねーよ

こんな意味不明なことを覚えていられるほど人生長くない

結局PythonとかGo言語現実的な解で黒魔術のある言語なんて意味ない要らない使わない

2017-02-26

プログラマな人に質問

最も得意な言語とその言語を書くにあたって、絶対にゆずれないコーディングルールを 3 つあげてください。

例えば、

  • if や for の { は絶対次の行
  • セミコロンは書かない
  • 終わりの ) はまとめて書く
  • 無限ループは while(1) じゃなくて for(;;)
  • int num;if(flag){num = 1;}else{num=2;} みたいなどちらか代入するだけのものは if じゃなくて条件演算子にする

と言う感じのもの

2017-02-16

密度演算子時間発展

密度演算子運動方程式はとりあえず勉強

いろいろな形式があるようにみえるが、どうなんだろう?

ちっと考えよう!やっぱり本を見て

時間軸で記述したほうの教科書

購入するか借りるかしようしやう

2016-12-18

http://anond.hatelabo.jp/20161218230337

対偶になってないか論理演算子持ち出してるんだっていうの

計算であれば「出来ない=単なるバカ」になるから

日本語にしてしまうと余計な解釈余地が生まれから本来まれないが、こういった手前は謎理論展開するため)

http://anond.hatelabo.jp/20161218230258

恐らく。

計算として「答えは一意に求められる」ものでない限り、こういった手前は自己ルールでわけわからん理屈で変な答えを出してくるよ。

論理的演算子を出した意味はそういう事。

つの違いを考えれば、意図簡単に見えるだろうに……

http://anond.hatelabo.jp/20161218221325

義務権利」の件でもだけど、小学校並みの論理的思考が出来てない人が何か暴れてるよね

冬休みにはちょい早いような

A or B

A and B

ココらへんの論理的演算子とか恐らく見たことも無いぐらいのバカなんだろうなという想定は出来る

2016-11-26

根っから逆張り野郎なので

掛け算も足し算も順序はある派。

x+dxをdx+xとか書かれたらキレる。

掛け算も、小学校ルールと逆順に書くときは、「掛ける数は演算子」だと認識するようにしている。

「3.9+5.1=9.0」は減点対象 小学校算数の“奇習”が議論に

これも「9.0は減点」に賛成派。「有効数字ガー」とか言ってるバカがいるが、有効数字を考えるなら、例えば「3.9+5.01」なら8.9を正解にして8.91は不正解にしないと整合性が取れない。算数じゃなくなる。

畢竟これらの議論は、「数学的に同値だが形式的に異なる記述について、それらに異なる文脈的意味を持たせたり、一方のみを「適切」とすることにどれほどの理があるか?」という問題帰着する。この観点を持つと、「理あり」とされているものは実は多くあることに気づく。

たとえば分数の約分。ふつう最終的な解に「2/6」と書けば減点対象だ。(でも、この書き方だって有用性はある。ピザを6等分した後なら「ああ二切れ分だな」とすぐわかるが、「1/3」だとわからない。)

小学校なら「帯分数」とかいう謎の書き方もあった。あんな奇妙な書き方、中学校以降で書いた覚えがないのだが、小学校少なくともある時期は「5/3」というような答えは減点対象だったと記憶している。

こういった「既約分数で答えよ」「帯分数で答えよ」という暗黙ルールは、「足し算・掛け算はこの順序で書け」「小数点以下の0は省略せよ」というのと本質的に同じだ。数学的に同値な書き方のうち、一方をなんらかの意図強制させているのだ。

どのルールにも、それを強制する意図がある。「約分できることに気づかせる」「5/3は1+2/3であることを理解させる」「かける数とかけられる数、という役割の異なる数字があることを認識させる」「なるべくシンプルな形で書くことを心がけさせる」など。それに意味あるかないかは、教わった小学生たちが決めることだ。小学生たちから自分判断する」ことを奪っちゃいけない。

ネットに渦巻く算数教育への批判には、なんというか愛がない。小学校教員の知性への信頼も、小学生たちの知性への信頼も、全然ない。「こんなことを教える先生は頭がおかしい」「小学生にはこんな教育は混乱を招くだけだ」。そんなはずはない。先生だって交換法則くらい知っている。

小学生にも、もっと自分考える力があるはずだ。「掛け算は交換法則が成り立つが、割り算では成り立たない。なぜか?」「かける数とかけられる数には違いがあるのか?」こういった問いかけに、自ら考えさせることこそ教育だ。子供が持ってきた答案用紙に×がついているのを見て、「先生が間違っている」という「答え」を教えてはいけない。「君はどう思う?」と問いかけることから教育が始まる。

2016-09-19

http://anond.hatelabo.jp/20160919121645

最近の若者ワンライナーなのか、3項演算子使わないと馬鹿にされるのか知らないけれど、

賢そうな構文は使わなくていい。

boolean check(int param, int param2, int param3)
{
    if ( param == 0 && 判定(param2) )
    {
        return true;
    }
    else if ( param3 == false )
    {
        return true;
    }
    else
    {
        returnn false;
    }
}


void main()
{
    if ( check(param, param2, param3) )
    {
        //したいこと
    }
}

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-05-07

http://anond.hatelabo.jp/20160506174221

3項演算子でよく言われた

逆にビット演算してないでa[0]+a[1]*0x100みたいなのでダメ出しされたり

2016-05-06

http://anond.hatelabo.jp/20160506174221

シフト演算子を使うのは、基本的には、シフト演算それ自体をしたいときにするべきだ。

最適化の弱いコンパイラパフォーマンス稼ぐためにやる場合もあるかもしれないのでその場合例外として)

8倍したいとか16倍したいとかをシフト演算に書き直すのは好ましくない。

もし将来的に12倍とか18倍とかに変わったらめんどくさいだろうという問題もある。

シフト演算子使うなって言われた

リーダー「ここの処理普通に書いて」

俺「どこがおかしいんですか?」

リーダーシフト演算子使わないで。可読性下がるから。」

俺「…」

これって俺が悪いのか?

別にコーディング規約にそんなこと書いてないし、

この仕事やっててシフト演算子ときで可読性って呆れてしまった。

やってられんわ。

2016-04-08

http://anond.hatelabo.jp/20160408140032

「逆」はこの文章では「面白い」にしか掛かってねえよ。賛成の反対の反対はなんなんだっツー話だろ。原則的オペレーションの近くにある値に演算子適用されるもんなんだぜ。(例外は沢山あるけど)

2016-02-29

http://anond.hatelabo.jp/20160229094157

じゃあもう1つ上の視点から俯瞰的説明しよう。

ハイパー演算子という考えがあって…

細部を全然理解してない人に、全体像を教えるのはもっと難しいか。

2015-11-16

.NET Framework ( C# ) LINQ の Count

Where やら Select などのメソッドのうしろメソッドチェーンでくっつける Count は、プロパティではなくて、メソッドなのだね。

なので Count() と記述する必要がある。でないと

エラー 演算子 '==' を 'メソッド グループ' と 'int' 型のオペランド適用することはできません。

といったようなエラーが表示される。

2015-08-24

http://anond.hatelabo.jp/20150824173736

PHP5.6だと演算子オーバーロードが出来るから、==で全く違う文字を比較しても意味が同じならtrue返すように出来るで。

2015-08-10

Pythonの条件演算子(三項演算子)に対する2chの反応

580 :デフォルト名無しさん[sage]:2006/07/26(水) 00:33:38

普通に三項演算子 ? : いれた方がよかったんだと思うけど、そうできない理由があったのか?

581 :デフォルト名無しさん[sage]:2006/07/26(水) 00:37:57

>>580

ああすごい同意

なんで三項演算子入れないで、あんなきもい

構文入れるんだよ。

583 :デフォルト名無しさん[sage]:2006/07/26(水) 00:44:31

つか、一種の3項演算子じゃん。

[x for y in z] とかとも類似する構文だし、俺はあれでいいと思うけどなぁ。。。

584 :デフォルト名無しさん[sage]:2006/07/26(水) 00:45:26

>581

入れたくないものを仕方なしに入れるから

とか? (本音を言うと誰にも使って欲しくない)

585 :デフォルト名無しさん[sage]:2006/07/26(水) 00:46:03

? : が既に使われててダメだったなら

C then X else Y

みたいにできなかったのか疑問

条件が真ん中に来るとか見づらいよ……

586 :デフォルト名無しさん[sage]:2006/07/26(水) 00:46:09

別にCに合わせる必要はないと思うよ。演算子関係ではCと違う部分がいっぱいあるから

半端に似せて「Cと同じだ」とか誤解を招くのはよろしくないと思う。

587 :デフォルト名無しさん[sage]:2006/07/26(水) 00:48:42

"x for y in z"

  ←  ←

データの流れが見える

"X if C else Y"

↑      ↑

分かれていて嫌

588 :デフォルト名無しさん[sage]:2006/07/26(水) 00:57:28

>>587

気持ちはわかる。対称性が悪い感じだね。

でももう決まったことだし、個人的にはあまり気にしないで使うことになるだろうな。

意見を述べるならもっと前に言うべきだったってことでしょう。

591 :デフォルト名無しさん[sage]:2006/07/26(水) 01:07:32

初めてリスト内包を見たときは「何じゃこりゃ、ワケわかめ」という印象だったけど

もう慣れてしまった。今ではリスト内包直観的で分かりやすいと感じる。

ずっと Guido のセンスで取捨選択してきたわけだし、ぶっちゃけ今のところこれといって

ダメ杉な仕様とゆーのは思い付かない。

今度の新しい三項演算子も慣れたら普通だと感じるようになるんジャマイカ

592 :デフォルト名無しさん[sage]:2006/07/26(水) 01:13:04

X if C else Y

「Xなんだよ! まあCだったらの話だけどな そうじゃなければYでよろしく」

593 :デフォルト名無しさん[sage]:2006/07/26(水) 01:15:11

このスレ読んでるうちにだんだん慣れてきたw

594 :デフォルト名無しさん[sage]:2006/07/26(水) 01:16:06

リスト内包表記は書いちゃうけど読みにくいな

[x for y in z]

ここにたどり着く前に脳内スタック忘却を始めるw

[x for x in original_list if x>2 and x<5]

こっちは自分で書いてもコメント必要だww

595 :591[sage]:2006/07/26(水) 01:37:07

文が書ける文脈では普通の if 文を使えばいいわけで、

X if C else Y を使うのはきっと式の中がメインになるんだろうな。

lambda の中とかリスト内包の中とか。

functor = lambda x: x+1 if y > 0 else lambda x: x-1 if y < 0 else lambda x: x

とか、

delta = Numeric.array([[1 if i == j else 0 for i in range(M)] for j in range(N)], Numeric.Float32)

みたいな。>>593の言う通り、用例を考えていたらもう慣れてきた希ガス

596 :591[sage]:2006/07/26(水) 01:54:02

q, r = divmod(n, 10)

print "%d%s" % (n, "th" if q == 1 else "st" if r == 1 else "nd" if r == 2 else "rd" if r == 3 else "

th")

たくさん if ... else が続く場合はなかなか読みやす希ガス

601 :デフォルト名無しさん[sage]:2006/07/26(水) 11:08:59

>>596

その書き方が許されるとすると、かなり応用力がありそうですね。

実質任意バージョンでOKてことだから・・・

でも、あんまりやるとさすがに見づらい気もする・・・

596がすでにぱっと見ではよく分からない

602 :デフォルト名無しさん[sage]:2006/07/26(水) 13:39:10

やっぱり、判定式が真ん中に来ると読みにくいな。

A = if C then B else D

みたいな形の方が文章として読みやすいと思うんだが。

603 :デフォルト名無しさん[sage]:2006/07/26(水) 14:03:57

>>596

三項演算子いれて、

print "%d%s" % (i, r == 1 ? "st" : r == 2 ? "nd" : r == 3 ? "rd" : "th")

にしたほうが見やすくない?

607 :デフォルト名無しさん[sage]:2006/07/26(水) 15:15:14

>>602

A = B if C else D だと

CならばDと目が流れちゃうかもかも。

まあ、慣れれってことか。

608 :デフォルト名無しさん[sage]:2006/07/26(水) 15:28:49

まあ、ハズレのときはNoneが返る形ならば、

A = B or D で済むんだけどねぇ。

BがNoneならDって使い方。これは結構便利でよく使ってるんだけども。

いまだに

A = B and D は使ったことがないけども。

609 :デフォルト名無しさん[sage]:2006/07/26(水) 15:49:33

>>596

> たくさん if ... else が続く場合はなかなか読みやす希ガス

おお!まさにそう思うよ!急にこの演算子が大好きになった。

2015-07-01

http://anond.hatelabo.jp/20150630130047

ブックマークコメント

除外の演算子は分かるけどさベッドで寝転がってスマホでだらだら検索するときもいちいち使う?

入力文字変換めんどうだよね。

全部全角で入力できたらいいのに。

ピザ生地 除外クックパッド」とか

2015-03-17

perl引数の渡し方の流儀がよくわからない

と思ったんだけど,ちゃんと以下に書いていた.

perlmodstyle - Perl モジュールスタイルガイド http://perldoc.jp/docs/perl/5.20.1/perlmodstyle.pod

引数ハッシュで渡すかハッシュリファレンスで渡すかの問題は主に個人的スタイル問題です。

ハイフンで始まるハッシュキー (-name) や全て大文字ハッシュキー (NAME) は、普通の小文字の文字列が => 演算子で扱えなかった 古いバージョンPerl遺物です。

ということで結論

もっと早く調べておくべきだった.というかちゃんと教材を読めということか.

2015-01-27

pythonコードを書けば綺麗になるなんて幻想

python制御構文をインデント制御するって文法規則があるんだけれど、これには一つ例外があって

「カッコの中では自由に改行・インデントが出来る」ってのがある。これが結構曲者で、例えばfizzbazzであっても

for i in range(0,100):
  if (
  i % 5== 0 
  ):
    if (
    i%3 == 0
    ):
      print('buzz');
    else:
      print(
      'fizz'
      );
  else:
    print(i);

このように書ける。はっきり言えば糞コードだ。

カッコというのが複数演算を行ったりするためにある程度任意にインデントを付けられるようにしないと具合が悪いのはその通りだが、

そのインデントには規則が設けられていない。

複雑なプログラムになればなるほどカッコを多用するので、この傾向は大規模なプログラム程顕著になる。

「綺麗なコードを書きたいからpythonを覚えたい」それは「将来の夢は可愛いお嫁さん」と同じくらい、儚き夢であることを知ろう。

ってか、言語化できない演算子(**とか>>とか)が無駄にたくさん使えるのに、&&とか||とかが使えないってどういうこっちゃ。

綺麗なコードにしてえなら、そこらへん全部アルファベットに直すべきじゃないんか?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん