「Solaris」を含む日記 RSS

はてなキーワード: Solarisとは

2018-02-01

anond:20180201132629

IT業界10年でBSDサーバに遭遇したこと無いや

触ったのはLinuxSolarisAIX、あと少しだけIRIX

BSDは昔ヤフーで使ってると聞いたことがあるぐらい

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-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2014-05-23

Windows、というよりWindows Serverがクソな理由

WindowsというOSのものは、少なくともパーソナルコンピュータに入れるOSとしては、完璧ではないにせよ、それなりによくできたOSであることは認めざるを得ない。いや、Windowsは、パーソナルコンピュータに入れるOSとしては、Mac OS Xと並んで優秀だと思う。

Windowsパーソナルコンピュータの分野で支配的なシェアを誇っているのだから別にサーバの分野で頑張る必要なんか無かったと思う。こんなに不幸になるのなら、Windowsサーバの分野に来てほしくなかった。申し訳ないけど、それほどまでに、Windows Serverを扱うのは嫌だ。本当に嫌だ。

サーバとしての性能比較については、私はよく知らない。Windowsサーバがクソなのは性能だと言いたいわけじゃない。

WindowsというOSサーバの分野に参入するにあたって、絶対に修正するべきだった仕様修正されていないことに対して、私は主張したいのである

「2つのUSBポート英語キーボード(1枚目)→日本語キーボード(2枚目)を刺すと、2枚目の日本語キーボード英語配列として認識される仕様は、何とかならなかったのか!?

何故か知らないが、Windowsキーマップは1マシンに対して1つしか設定できない。同じマシンに複数のキーボードを指すと、仮にそれらのキートップ印刷されている記号の配置が異なっていても、一方がもう一方に従う。使用されるキーマップは、基本的にはOSが起動した直後、早い者勝ちである

これが問題になるのは、リモートデスクトップサーバ操作している際である英語キーボード愛用者である私は、サーバ再起動する権限を一切奪われてしまった。私がサーバ再起動すると、起動したマシンキー配置が英語になってしまい、私以外の日本語キーボードユーザ記号を一切入力できなくなるという問題が発生したかである一般的に、サーバ再起動する権限を与えられない理由というのはもうちょっとマトモなものであるという認識である

しかも、再起動する権限が与えられていないのはまだしも、結局そのサーバリモートデスクトップログインすると、その中の操作は全て日本語配列なのである自分PCの設定は英語なのに…この苦痛がご理解いただけますかねぇ!?

幸か不幸か、今の職場には日本人しかいないので、英語キーボードなんて使ってる奴の方がレアなのであって、駆逐されるのは私であるしかしこれから時代国籍言語が異なる中で同一の環境を弄ることなんて、割とよくあるタイプではないのか?例に挙げるのは不適切かもしれないが、例えばGoogleエンジニアが全員、同一のキーマップキーボードを使っているとは、到底思えん!Microsoft Azureはどうなんだ?1台のマシンにつきキーマップが1種類しか用意できないと、仮に海外から助けてもらおうとして遠隔で操作する権限を与えたとしても、キーマップロシアンルーレットになってたら、結局助けてあげられないんじゃないの?

…いやはや、まことに信じがたい仕様である。少なくともサーバOS仕様としてはクソ未満である文句なしにクソ未満だ。

確かに、時代進歩し、昨今はWindows上で動作するSSHデーモンもあるみたいなので、それを使用してPuTTYごしにサーバの作業をするという方法も、無くは無い。SSHであれば、キー配置が問題になるのはPuTTYの側であって、サーバの側ではない。だが…正直、SSH経由でWindowsサーバを使うなら、もはやサーバWindowsである必要は無いのではないか…?普通にLinux/BSD/Solarisでええやん…なんでWindowsなん…?

というわけで、Windowsサーバ開発チームに物申すことができるのであれば、同時に複数の(配列の異なる)キーボードを刺しても、よしなにしてくれるように改善していただきたい。それさえしていただければ、Server 2012のあのクソみたいなタイルUIにも喜んで乗り換える。マジで

2013-07-12

x86solaris6万円出して購入し、コマンド必死で覚えていたあの頃から

十数年でなんでも無料時代常時接続時代か…。

2013-01-18

続・うへぇ苦労するのガイドライン

前のはこれ http://anond.hatelabo.jp/20121219191602

PC-98

http://toro.2ch.net/test/read.cgi/unix/1036951410/601

601 :名無しさんお腹いっぱい。:2012/07/10(火) 15:04:00.62
今月はじめ、職場に古いパソコン(i486DX2の結構ローエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要がありハードパソコン系を採用するのは聞いていたの 
ですが、搬入されたパソコンのダンホール箱に印刷されていたのはPC-9801という 
文字でした。 

「うへぇ~、よりによって98かよ」 

NetBSD/OpenBSDインストール不可、Solarisも不可、SATA-HDDからブートできるのか、 
今時のLCDディスプレイにつながるのか、FreeBSD9.xは対応してるのか、 
今時のネットに繋いでもセキュリティ大丈夫なのか不安はつきませんし、 
非メジャーなのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にそれに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、唯一コンソールでの漢字ROMによる日本語表示ができたPC-98大学など 
教育機関に浸透していて、日本パソコン界に多くのバカを輩出しました。 

これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 
TeXが入らない、firefoxは使えないのか、Rubyが使えないのかなどと、 
サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 
鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去20年のパソコン界隈のくだらないそれらの 
議論が再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではPC/ATでもSPARCでもPA-RISCでも 
PowerPCでもなんでもいいですがメジャーかつ現行のマシンにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

Z80

http://toro.2ch.net/test/read.cgi/unix/992942337/737

737 :名無しさんお腹いっぱい。:2012/09/16(日) 16:27:31.40
今月はじめ、職場に新しい組み込みマシン(ファンレス結構省電力構成)が入りました。 
多分私が開発全般をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、プログラムアセンブラを使用するのは 
聞いていたのですが、添付のサンプルソースコードからチラッと見えたのは 
LD A,(HL)という命令でした。 

「うへぇ~、よりによってZ80かよ」 

アドレッシングモード皆無、リロケート不可、使いにくいインデックスレジスタ、 
今時の関数引数スタック渡しに対応できるのか不安はつきませんし、 
今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 
おそらく導入に際して、大学など教育機関最初Z80に触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、8bitCPUi8080上位互換i8085よりも多くのツギハギ命令を追加拡張した 
Z80大学など教育機関に浸透していて、日本CPU界に多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、ADD A,(HL)はできるのにADD B,(HL)は 
できないのかとか、相対アドレスのCALL命令はないのとか、 
スタックフレームポインタとして使いたいのにLD HL,SPっていう命令ないじゃんとか、 
アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからZ80使うんじゃねーよ) 
それと戦わなければならないのでしょう。そして時代によって決着している、 
過去30余年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの 
でしょう。もう今からうんざりです。 

だからお願いです。教育現場ではi386でもi568でもi686でも 
x86_64でもなんでもいいですが現行のCPUにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

xinit

http://toro.2ch.net/test/read.cgi/unix/1011306728/134

134 :名無しさんお腹いっぱい。:2012/07/15(日) 14:17:53.53
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、X Window System上のアプリケーションを 
使用するのは聞いていたのですが、OSを起動して黒いバックに白い文字だけの 
英語の画面に表示されていたのはlogin:というプロンプトでした。 

「うへぇ~、よりによってxinit方式かよ」 

CUIログインなんて古い、コマンド入力なんて古い、今の奴は日本語入力設定大丈夫 
なのか(XMODIFIERS)、今時のマルチシート環境対応できるのか不安はつきませんし、 
xinitユーザーが少ないのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にxinitに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、X11で唯一$HOME/.xinitrcを手書きするというCUI方法環境設定できた 
xinit方式は大学など教育機関に浸透していて、日本X11界に多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、GNOME/KDEはどうやって起動するのか、 
ウィンドウマネージャを終了したらXごと落ちたとか、ck-xinit-sessionはないのか 
などと、X11通気取りの偏ったどうでもいい我侭を言い出し(だからxinit方式にするん 
じゃねーよ)それと戦わなければならないのでしょう。そして時代によって 
決着している、過去25年のX11界隈のくだらないそれらの議論が再現され、 
それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではgdmでもkdmでもwdmでも 
xdmでもなんでもいいですがグラフィカルなディスプレイマネージャにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

tcsh

http://toro.2ch.net/test/read.cgi/unix/1094041299/383

383 :名無しさんお腹いっぱい。:2012/07/12(木) 19:20:13.06
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、制御コマンドとしてシェルスクリプトを 
使用するのは聞いていたのですが、そのファイルを開いて1行目に書かれていたのは 
#!/bin/tcshという文字列でした。 

「うへぇ~、よりによってtcshかよ」 

ファイル記述子のリダイレクト不可、クオートのネスティング等に無理あり、 
今の奴でさえシェル関数は使えないし、パイプラインの終了ステータスおかしいし、 
今時の担当者が扱ってセキュリティ大丈夫なのか不安はつきませんし、 
スクリプトとしてのcshは嫌われるのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初cshに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、シェルで唯一aliasやhistoryやジョブコントロール機能が使えた 
csh大学など教育機関に浸透していて、日本シェル界に多くのバカを輩出しました。 

これから私は、おそらくそういうバカが、$*でスペース入りファイル名が扱えないとか 
$<でファイルから読めないのかとか、if文の条件式のコマンドリダイレクト 
できないのかなどと、シェル通気取りの偏ったどうでもいい我侭を言い出し 
(だからcshスクリプト書くんじゃねーよ)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去25年のシェル界隈のくだらないそれらの議論が 
再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではbashでもzshでもkshでもashでも 
Bourne shでもなんでもいいですがBシェル系のシェルにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

続く。

2012-12-19

うへぇ苦労するのガイドライン

見出し

Vine Linux (多分元祖)

http://engawa.2ch.net/test/read.cgi/linux/1263028279/298

298 :login:Penguin:2012/03/14(水) 06:01:43.41 ID:gAhyxynR
>>283   

>>291がVineを押してますが…  
 今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。多分私が運用保守をまかされそうな 
雰囲気です。業務的にとある構造分析シミュレーションなど行う必要がありOSLinux採用するのは 
聞いていたのですが、搬入されたPCのダンホール箱に乗っかっていたのはVineインストールパッケージでした。 

「うへぇ~、よりによってVineかよ」 

カーネルが古い、日本語環境が古い、ソフトが古い・揃ってない、今の奴は日本語文字コード大丈夫なのか(utf-8)、 
x86_64環境大丈夫なのか、今時のネットに繋いでもセキュリティ大丈夫なのか不安はつきませんし、 
非メジャーなのでネット上の情報もすくなく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にそれに触れてすりこまれた人間強気知ったかぶりをして 
発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。  

昔、当時、唯一日本語環境が充実していた(*)Vine大学など教育機関に浸透していて、日本Linux界に多くのバカを 
輩出しました。((*)昔の話です。現在はutf8対応sambavfs対応など使い物にならないレベルで遅れていそうです) 
これから私は、おそらくそういうバカが、emacsを入れさせろ、Texを入れさせろ、コンソールでEUCは使えないのか、 
crond使えないのかとかなどと、サバ缶気取りの偏ったどうでもいい我侭をいいだし、(だから鯖にするんじゃねーよ、 
鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。そして時代によって決着している、過去20年の 
Linux界隈のくだらないそれらの議論が再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 
 
だからお願いです。教育現場ではubuntuでもdebianでもFedoraでもRHELでもopenSUSEでもなんでもいいですが 
メジャーかつ現行のものものにしてください。Kernel2.6 gcc4 glibc2.4 GNOME3/KDE4が最低ラインです。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

Solaris

http://toro.2ch.net/test/read.cgi/unix/999172129/740

740 :名無しさんお腹いっぱい。:2012/03/15(木) 13:42:50.73
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要がありOSUNIX系を採用するのは聞いていたのですが、 
搬入されたPCのダンホール箱に乗っかっていたのはSolarisインストールパッケージ 
でした。 

「うへぇ~、よりによってSolarisかよ」 

カーネル再構築不可、コマンドが変・オプションがない、KDE環境がない、 
今の奴は日本語文字コード大丈夫なのか(ja_JP.PCK)、x86_64環境大丈夫なのか、 
今時のネットに繋いでもセキュリティ大丈夫なのか不安はつきませんし、 
非メジャーなのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にそれに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、唯一フリーウェアのmake一発率が高かったSunOS大学など教育機関に 
浸透していて、日本Solaris界に多くのバカを輩出しました。 

これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 
TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかなどと、 
サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 
鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去20年のSolaris界隈のくだらないそれらの議論が 
再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではUbuntuでもDebianでもFedoraでもRHELでも 
OpenSUSEでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

SCSI

http://toro.2ch.net/test/read.cgi/unix/1000022300/812

812 :名無しさんお腹いっぱい。:2012/07/18(水) 15:51:49.38
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、拡張カードを刺してHDDを増設して使う 
ことは聞いていたのですが、納品された拡張カードに書かれていたのは 
AHA-2940Uという型番でした。 

「うへぇ~、よりによってSCSIかよ」 

たった20MB/sコネクタもケーブルも太くて古めかしい、今の奴はOS入れても 
/としてマウントできるのか、今時の高速HDD対応できるのか不安はつきませんし、 
SCSIユーザーが少ないのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初SCSIに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、唯一HDDCD/MOテープドライブ等を外付けにでき、デイジーチェイン拡張性が高かったSCSI大学など教育機関に浸透していて、日本ストレージ界に 
多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、ターミネーターが無いよとか、 
SCSIケーブル全長1.5mだっけ? 6mじゃないの?とか、SCSI IDがぶつかっちゃった、 
などと、SCSI通気取りの偏ったどうでもいい我侭を言い出し(だからSCSIにするん 
じゃねーよ)それと戦わなければならないのでしょう。そして時代によって 
決着している、過去25年のSCSI界隈のくだらないそれらの議論が再現され、 
それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではSATA1でもSATA2でもSATA3でも 
eSATAでもなんでもいいですがシリアルATAHDDにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

twm

http://toro.2ch.net/test/read.cgi/unix/1061122459/497

497 :名無しさんお腹いっぱい。:2012/08/03(金) 20:34:26.89
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、X Window System上のアプリケーションを 
使用するのは聞いていたのですが、X11を起動して表示されたのは、 
白黒メッシュのバックに平面的な緑の枠のウィンドウマネージャでした。 

「うへぇ~、よりによってtwmかよ」 

カラーXpmアイコン表示不可、ウィンドウ最大化とかできない、 
GNOME対応、今の奴はタイトルバーに日本語表示大丈夫なのか、 
今時の仮想デスクトップ環境対応できるのか不安はつきませんし、 
twmユーザーが少ないのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初twmに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、X11で唯一標準ウィンドウマネージャとしてソースツリーに含まれていた 
twm大学など教育機関に浸透していて、日本X11界に多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、GNOME/KDEウィンドウマネージャtwmに 
設定できないのかとか、$HOME/.twmrcを設定するGUIツールはないのかとか、 
タスクバーはどこにあるのかとか、X11通気取りの偏ったどうでもいい我侭を言い出し 
(だからtwm使うんじゃねーよ)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去25年のX11界隈のくだらないそれらの議論が 
再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではmetacityでもkwinでもfvwm2でも 
mwmでもなんでもいいですが普通ウィンドウマネージャにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

続く。

2012-03-24

簡単なクローラ作るならPythonだよ!

http://d.hatena.ne.jp/nishiohirokazu/20120323/1332504404

最近Webクローラクライアントを作るお仕事が増えた。WebクローラクライアントというのはHTTP(S)を介して様々なファイルダウンロードして解析し、結果を溜め込むだけのプログラムであるボットともいう。

クローリングの規模が大きくなると、クロール処理部と結果貯蓄部を分離する必要がある。クローラには様々なものがあるが、ものによっては特定のサーバに集中的にクローリングを行うこともある。このとき、1つのIPを使って集中的にクローリングを行うと、攻撃とみなされ一瞬でbanされてしまう。そこで、一見するとまったく関係なさそうなIPを複数確保し、それぞれにクローラーを仕掛けて走らせるのである

結果貯蓄部は、要するにデータベースサーバであり、何を使用しても良い。クロール処理部とのやりとりに使用するプロトコルRDB依存プロトコル(MySQL Socketとか)でもHTTPでもなんでもいいが、とにかくクロール処理部が解析した結果を随時溜め込めるようにしなければいけない。逆に言うと、まぁ、口さえできるのであれば何を使用しても良い。

問題は、クロール処理部に何を使用するかである。おおまかな要件は次の通りである

これらの要件を満たそうとすると、ぶっちゃけJavaPythonくらいしか選択肢が無い。

JavaPython
HTTP(S)HttpURLConnectionかApache HTTP Clienturllibかurllib2
環境依存Write once, run anywhere (VM最初からインストールされてるのはSolarisくらいのものだが、どんなOSでも大体はすぐインストールできる)UNIXであればほぼ標準で入ってる、Windowsインストーラも用意されている
キャッシュ機能JDK6にDerby標準搭載Python 2.5からsqlite3標準搭載

JavaPythonの違いは山ほどあるが、簡単なことをやらせるだけならPythonJavaよりも使用メモリが少なくなりがちなので、そういう場面であればPythonは(現時点においては)最強の座に君臨すると考えられる。

余談であるが、私が本当に好きなのはPerlであり、

という条件下であれば何の迷いもなくPerlを使っていたであろう。畜生

2010-06-02

Twitterこっそり系クライアントまとめ

Twitterこっそり系クライアントを探したら色々あったので、そのまとめ。

元ネタスラドの記事

職場Twitter をこっそり見るには? - スラッシュドットジャパン

http://slashdot.jp/it/article.pl?sid=10%2F05%2F31%2F0121241

他にもあればまとめます。

2010-03-25

タイポ

VirtualBox上のゲストOSUNIXLinux)で共有フォルダマウントする時

mount ... vboxsf ...

って感じのコマンドを使いましょうって書いてあるサイトが多いけど、漏れSolaris 10で試したら

vboxsf → vboxfs

が正しかったよ。

何なんだ?

2010-03-24

俺 V.S. Solaris 10

初めてのUNIXがこんなに手強いとは思わなかったよ!

助けて……

2009-03-21

Sun MicrosystemsIBMに身売りするかもしれないという話。

Sun Microsystemsの株を買って取締役を送り込んだ投資ファンドが、株価を引き上げる手段として、IBMとの合併話をでっち上げているようである。

株価を引き上げて売り逃げしないと、投資したお金現金化できない。本業でがんばって企業価値を高めて、株価を引き上げて利益を得るというのが、投資ファンドの本来の存在価値なのだが、実際には、ほとんどの投資ファンドが、このように、短期での転売益を目的として行動を取っている。

株式を買い占める過程で株価を吊り上げてしまったので、それまでの配当では利回りが悪すぎる。吊り上げた価格正当化する為に、より大きな企業吸収合併してもらい、時価総額現金化するのである。

バブル期ならば、これは十分に成立した。お金が余っているのだし、資金規模の大きい所は、手持ちの資金の運用先が無い。新事業を立ち上げるよりは、すでに成立している事業を買い取って傘下に加えるという手法は、経営者にとって、失敗した時の責任を回避しつつ、成功した時のメリットを独り占めするという目的に合致しているので、そのような仲介を主な仕事にしているインベストメントバンクが、雨後の筍のように発生したのである。

実際には、そのようにして合併された企業の大部分が、買収価格に見合う利回りを発生できていない。

IBMにとって、Sun Microsystemsを買い取っても、メリットは無い。Sun Microsystemssolarisは、独自CPUであるSPARCの開発まで行われており、ハードウェアOSをセットで使った時に最高の性能を発揮できるようになっている。IBMAIXも同様である。つまり、吸収合併しても、当分の間は、異なる製品ラインを持つ事になる。一本化するまで、社内に二系統の指揮系統を残さなければならず、統合の効果が出ないのである。

どうせ売るならば、サーバー業界に新規進出したいと考えている企業ターゲットにするべきであろう。そう、独自のハードウェアを作るセクションもノウハウも無いのに、サーバーOSを作っているところとか

http://technet.microsoft.com/ja-jp/windowsserver/default.aspx

の方が、まだ、売れる可能性はある。

2008-10-11

私のプログラム

初めは小学生の頃か。

実物のスペースインベーダー記憶はない。

しかし、それを皮切りにアーケードゲームのみならず、ゲームウォッチ、ケームセンター嵐などを経て、ファミコンが登場する「ゲーム」の時代だった。

「ゲーム」コンピューターゲーム意味になった時代だった。小学生も「コンピューター」にワクワクした。

21世紀コンピューターにより人工知能ができる。そんな時代だった。

でも、アルファベットを知らない小学生BASICは難しかった。ぴゅう太がせいぜいだった。

中学生学校PC-9801があった。後のパソコンである。

PRINT」で文字を表示する。「GOTO」で行き先を変える。それは分かった。でも何をすればよいか分からなかった。

だから「ベーマガ」で16進数を打った。でも動かなかった。何度も調べ、直し、試した。デバッグした。

してようやくゲームが動いた。ゲームはつまらなかった。

でも動いた。自分の入れた文字で数字でコンピュータが動いた。自分で動かした。動かせた。

BASICで線を引きマシン語で文字を動かした。

高専に進んだ。Turbo Pascalコラムスもどきを作った。

初めてフルスクラッチで書いた。配列も使った。

小学生のころから6年が過ぎていた。

Turbo Cも使った。IDEで使うそれは、インタプリタのノリだった。

FM-Rレイトレースもした。一晩かけて、エラーが起きていた。

でも、構造プログラミングを学んだ。ポインタも学んだ。マシン語の知識が役立った。

Solarisも使った。EmacsやXも使った。オブジェクト指向も知らずC++にも触れた。

GC構造体を代入して使い回し、Xサーバを落した。

家のノートFreeBSDを入れた。rootになった。

awksed正規表現を学んだ。そしてperlに出会った。

コラムスもどきを作ってから6年が過ぎていた。

テレホーダイにした。Mewを使った。チャットをした。

perlで掲示版の書き込みをチェックし、madokaで遊んだ。CGIを書いたりした。

脆弱性を見つけた。作者にメールした。ドキドキした。

perlと出会ってから6年が過ぎていた。

オープンソースプロジェクトに参加した。

はてなに出会った。JavaScriptに出会った。

BookmarkletgreasemonkeyAjaxオブジェクトだらけだった。

初めはゲームだった。でも最初だけだった。

ハードを叩き、ライブラリを叩いていた。

サーバを叩き、ブラウザを叩いてきた。

気が付いたら24年が経っている。

今、pythonで書いている。

ようやく、言語の違いには慣れてきた。でも、まだLISPを使った事はない。

道はまだまだある。未知の世界につながっている。

作りたい物が本当は何かは分からない。作れる物が本当は何かは分からない。

でも、何かがあるような気はする。だからプログラムしてみる。

どんなふうに動くのかは分かってない気がするけれど、分かっている事もある。

今も「コンピューター」にワクワクしている。

それが今の私のstatusだ。

http://anond.hatelabo.jp/20081011173016

2008-07-21

http://anond.hatelabo.jp/20080721042906

誤解があるのかな?

元増田HP-UXなどのシステムメインフレームを一緒くたにしてるので違和感が。

用語の定義が違ってると混乱しそうな気が。

増田オープンシステムってのはUNIXSolarisHP-UXAIX)、Windowsのことだと理解している。Linuxも当然含むけど。

システムによってはメインフレームから代替可能だし、HA、ミッションクリティカルメインフレームとは必ずしもなってないと思う。

ただ、オープンとはいってもソフトウェアクローズドなのでここもオープンに、ってことでOSもミドルもオープンOSS)に移行しようとしてるように見えるがまだ難しそうなイメージ

イメージとか聞きかじった情報でも良いのだが、どこがダメでどうゆうシステムが良いと考えてるのが知りたいという気がするな。

2008-06-10

諸君、私はC++が好きだ

諸君、私はC++が好きだ

諸君、私はC++が好きだ

諸君、私はC++が大好きだ

演算子オーバーロードが好きだ

テンプレートが好きだ

STLが好きだ

Boostが好きだ

FC++が好きだ

Windows

Mac

Linux

BSD

Solaris

この地上でコンパイルされるありとあらゆるC++が大好きだ

演算子を多重定義できるC++が好きだ

演算子意味が変わり、直感的なコードが書き下せる時など心がおどる

テンプレートが使えるC++が好きだ

動的言語の優位性を語っている奴等にそれを見せた時など胸がすくような気持ちだった

Boostが好きだ

Boost::lambdaを使って(_1 + _2)と二つの引数を足算した結果を返す無名関数を定義した時など感動すらおぼえる

Boost::regex正規表現を書く時などもうたまらない

Boost::shared_pointerでオブジェクト自動的に解放されるのは最高だ

納期に追われて急いで書かなければならないパーサを

Boost::spiritBNF記述して書いた時など絶頂すら覚える

マルチパラダイムC++が好きだ

そんなC++が複雑だと思われているのはとてもとても悲しいものだ

テンプレートが好きだ

エラーメッセージ意味不明だと言われるのは屈辱の極みだ

諸君 私はC++を 変態の様なC++を望んでいる

諸君 私に付き従うC++好きの諸君 君たちは一体何を望んでいる?

更なるC++を望むか 

糞の様なC++を望むか?

BoostFC++によってさらに変態的になっていくC++を望むか?

C++!! C++!! C++!!

よろしい ならばC++

だが、LL全盛の時代の陰でもはや組み込みHPCぐらいでしか使われないという中傷に耐え続けて来た我々には

ただのC++ではもはや足りない!!

C++を!! 一心不乱の大C++を!!

我々はわずかに小数

PerlPHPPythonRubyJavaScriptに比べれば物の数ではない

だが諸君は一騎当千のBinarianだと私は信じている

ならば我らは諸君と私で総兵力100万と1人のコンピュータサイエンティスト集団となる

我らを忘却の彼方へと追いやり、インタプリタしか知らない連中を叩きのめそう

髪の毛をつかんで引きずり下ろし 眼(まなこ)をあけて思い出させよう

連中コンパイラの偉大さを思い出させてやる

連中インタプリタでは実用的なプログラムが書けないということを思い出させてやる

C++には奴らの哲学では思いもよらない書き方がある事を思い出させてやる

1000人のBinarianの集団で 世界変態的なコードで埋め尽くしてやる

目標 世界のありとあらゆるプログラム

一億総合コンパイル作戦 状況を開始せよ

逝くぞ 諸君


http://wids.net/lab/sukida.htmlで生成。

2007-12-13

http://anond.hatelabo.jp/20071212200140

残念ながらMaczfsはまだ使えない。

Solarisからzfs領域をnfsエクスポートしてMacからマウントするのが最善かな。

netatalk使ってafpで公開するのでもいいけど。

こんなOS使ってんだぜ、すごいだろ!うほほーい!

みたいな選民思想を抱くことって俺の場合よくあるよ。

「今どきWinMacしか使えないなんてテラワロスwww

って言ってたら、「SolarisやらTronやら使えないなんてテラワロスwww」って言い返されて、

半べそかいたのはいい思い出です。

2007-09-01

9月になったし、もうそろそろ書いておくか

これから就職活動するバカはいないだろうけど、そういう人もいるだろうから少し書いておこう。

どちらかというと、アンチMS派なUnix技術者Windowsだけの世界で仕事をする辛さを。

Unix技術者は、業務実績にSolaris/AIX/Linuxって書いてあってもちゃんと質問しろ。Windows仕事は無いですよね?って。

僕が食べるために職を手にしているこのIT業界というのは、バッドノウハウMicroSoftExcelで出来ている。

その為、僕が手にしたUnixの知識は、特定の仕事以外でしか役に立たないし、使わない。

viだろうが、TeXだろうが、Xの知識よりも、MFCVBAのちょっとした知識のあるヤツが上にみられる。

ExcelWindowsの知識があればそれだけで仕事になるからだ。

いいか、viTeX、Xなんて捨てちまえ、Excelがあればそれでいいのだ。

Unix技術者でいうハッカーとはなんだろう。

MSでは、ActiveXを使ってCOMを操作し、クライアントレジストリを操作し、IE単体でできないことをやってしまうヤツがハッカーと思われている。

VBAマクロで作ったなんちゃってツールを3時間で作れるほうが、

perlruby/pythonで、より少ない時間で作ったツールよりも凄く思われてしまう。

そして、それができるヤツの方が、Unix技術者よりもよりハッカーであり、技術力があると思われている。

ブラウザを例にしたが、

javascriptでalert/confirmを出すよりも、vbscriptでMsgBoxの方が多くのことができるから、

javascriptNumberの計算よりも、vbscriptでDecimalを使った方が倍密度の計算ができるから、

vbscriptを駆使できるヤツは、凄く重宝される。

いいか、javascriptで汎用的に書くのなんてナンセンスだ。javascriptなんて捨てちまえ、覚えるのはJScript実装(WSH)だ。

この業界、何が不満になるかというと、

MSの、もっというとWindowsのことしか知らないヤツが多すぎるということ。

そういうヤツらは、Windowsだったらこんなこともできるのに、なぜUnix/Linuxだとこんなこともできないのか。と言う

そういうヤツらは、Windowsの未修正バグの合間を縫いながら中途半端な実装しかしない。

だって、中途半端(もしくは大雑把)な実装で動いているものの中で動くから。それ以上に実装しようとしてもできないのだ。

いいか、win32のメッセージングの仕組を覚えるんだ。無理矢理send_keyみたいなコードを書けるようにしろ。

コマンドを連結するよりも、結果に近いコードを書くんだ。線形になろうがヤツらは気にしないだろう。

ヤツらは、javapythonをバカにする。

何故か。

それは、.NETで作ればお客さんの要望が実現でき、Excelと連携できるからだ。

ヤツらは、C/Sの世界でこそ役に立つ技術者だが、Webの世界に連れてきてはならない。すぐに実装がIEだけになる。

ヤツらにLLを覚えさせるのは無理だ。

クロージャなんて知らないし、高階関数カリーなんてコードを教えてみろ。後から辛くなるのは自分だ。

ヤツらにはPHPを教えておけ、それだけで満足する。すごいヤツになった気にさせれる。

バッドノウハウ慣れしているヤツらはそれを使ってコードを書いてもらえ、rubyで書かせるよりも修正が20倍楽だ。

いいか、まとめるぞ。

今まで一生懸命Unix勉強してきたのは無駄だ。いますぐ忘れるんだ。

Excelを今から覚えろ。VBAを覚えろ。そしてMSの動きを身に着けるんだ。

Windowsでは単位がFormだ。それが標準出力標準入力と思え。ときどきSheetとかWorkbookになるぞ。

ストリームファイル操作には気をつけろ。Unixの気分でいると思わぬところで抜けが出るぞ。

IRCは使うな。Jabberを使うな。メッセンジャーを使え。移行のお薦めはGaimだ。Windows版がある。

viの使用頻度を減らせ、変なコマンドを身に着ける前に、秀丸マクロを書けるようにしろ、Notepadのショートカットを覚えとけ。

BindとかApache(Httpd)の知識はいらない。IISだ。ActiveDirectoryだ。

文字コードはCp943cを何がなんでも押せ。Shift_JISっていう大雑把な伝えかたはダメだ。絶対cp943cにしろ。UTF8/UTF7との格闘で身も心もぼろぼろになるぞ。

汎用性なんて無いんだ。Windowsというプラットフォームがあれば。



ああ、心が渇いていく。

2006-12-27

Solaris8(SPARC)でcoreって原因が本当にわからなかったから

上の立場((シニアプログラマ))の人がSunに送ったら、

担当者がVacation中なので回答まで時間がかかります。

という内容のメールの返信がたどたどしい日本語で。

そんなこともありました。((結局どうなったんだろう・・・))

Solaris(Kernel)のパッチは内容をちゃんと読むと面白いよ。

# 「なんとか関数エラーなのに正常値を返却する問題」とか。

Sun儲を目指す君へ

LinuxSolarisHP-UXWindowsもやってきたけど、決して保証に対する意識は捨てていない。

むしろ、積極的に保証から逸脱しようとするエンジニアがいること自体が驚きである。

機能要求と製品選定のバランスを無視して、という意味で。

今は製品としてのLinuxを売っていますが、ユーザ保証対象外になることは決して勧めません。

そこを逸脱することは、製品の使用法から逸脱することです。

そうなれば既に販売者としてできることはありません。すべてユーザ責任です。

製品以外のLinuxを使うのであれば、そもそも保証対象内であるか外であるか考える必要はありませんね。

確かにSolarisには動作保証サポートがあります。

ありますが、それは自分の希望する対応や回答が100%保証されるわけではありません。

ベンダーも商売です。金銭的な影響が少ない修正や機能追加には消極的です。

当然ですが、同じことは商用Linuxにも言えます。

それから、システムユーザのものであってベンダーのものではありません。

ベンダーに頼んでも、自分のリスクが無くなるわけではない。

あくまで対価を払って物の納入や作業をしてもらうだけです。

http://anond.hatelabo.jp/20061226145441

とにかく「もうすこしがんばりましょう。」

2006-12-26

linuxsolarisサーバ技術者を目指す君へ

linuxフリーOSでもちろん保証はない。

金融系や大規模インフラ系のシステムlinuxを使うのは、システムを受注したベンダーとしてすごく勇気がいる。

一方、solarisは商用なので保証付き。

金融系や大規模インフラ系は、ほとんどがsolarisなんじゃないかと思う。

linuxにもRedhatエンタープライズ版があるけどsolarisのほうが全然需要がある。

止まることの許されない金融系や大規模インフラ系では特に。

なんでそこまでベンダー保証にこだわるか、それは損害賠償があるから。

例えば、どこかの銀行システムが止まりました。おかしな挙動をしました。

それで損害が出た場合、ベンダーには何千万とか何億とかの賠償がふりかかる。

だからより保証のあるsolarisを選ぶんだと思う。solarisライセンスなんて安いもんだ。

前置きが長くなったけど今日あることに気づいたんだ。

同じサーバ構築やってる人間でも、linuxsolarisかで全然違う人種になる。

linuxでやってきた人間solarisと比べて保証に対する意識がゆるい。

マニュアルは必要なところをかいつまんで見るもんだと思ってる。

実際に動けばいい!という発想で納品してる。

solarisでやってきた人間は、保証に対してかなり敏感である。そういう案件が多かったのだと思う。

まず、マニュアルからそれることを極端に嫌がる。少しでも違う方法をとると保証対象外になってしまうから。

それが実際に動いたかなんて理由にならない。自分の作業が保証できるかってことが最重要になる。

で、サーバを構築する人間としてどちらに需要があるのか。

大きな案件としては、solarisが多いと思う。報酬としてもsolarisのほうが多い気がする。

小さな案件では、なるべく低コストを意識しているので、linuxが多いのかもしれん。

ただ、低コスト目的linuxを使って構築しても、運用していてそのサーバに問題があった場合にlinuxのわかる技術者がいないと意味がない。

そういう意味では、solaris保証付きで安心だ。書かれている通りに構築して問題があったら保証してくれるのだから。

solarisの案件を取るかlinuxの案件を取るかと迷ったらlinuxを取れ。

なぜなら、ベンチャー企業を作るにしても入るにしてもシステムsolarisを選ぶ余裕はないからだ。

一番重要なことは仕事環境だと思う。solaris保証保証に慣れると、オープンソースを見下し始める。保証対象外だから。と。

一生サラリーマンエンジニアサーバ構築するならどうぞsolarisを選んでください。

今は、linuxの案件は少ないと思うけど地道にlinux仕事を探そう。

これから日本のITベンチャーはもっと活発になると思う。はてなmixiシステムlinuxだ。

googlelinuxで安くシステムを作ったじゃないか。わかってる堅実に安定した生活がしたいならsolarisだよ。

ただベンチャー思考の君がsolarisの案件を選択するのはどうかと思ったんだよ。

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