職場の人と話してた時に「その話ネットで見た」みたいに言われたんですが。
それ多分私のブログです。
職場ではイチイチ言ってませんが。
ま、そんなものです。
先代の人からそんなんでしたが（会社の人には知られていないが外部からは見える、みたいな）、
今ウチの会社の人ってあんまり外部発信なりネットヲチなりしてないんですよねー。
会社からは多分「役に立ってないけど売上も上がらない人」みたいな感じに見えてると思います。
まあいいけど。
システム開発の会社なのに、技術とか全く評価されない会社なんでまあもうどうしようもないですねえ。本気で転職活動でもするか・・・・・・でも転職しちゃうと上司も先輩もやっちゃったので、残された人が悲惨になりますからねえ・・・・・・
SAS on Linuxを色々試しているのだけど、今の時代において
「UTF-8はフルサポート出来てません」
というのはホント如何なものかとは思う。
プロセス自体は対応出来ていても、DMSの対応が遅れているだとか、ホント困るんだが。
コアプロセスのイメージが更新出来ていないのよな、今でも。個々のクライアントモジュールは最初からUTFだぜなJavaとかなんでいいけど。
あと、XPTファイルでの対応が地味に首が絞まっている。
XPTファイルはASCII前提の時代に作られたフォーマットなので、DBCSに厳密には対応していない。
ゆえにエンコーディング情報も持ってないし、もう少しマシなトランスポート形式を作ってほしいものである。作らなくてもそのうちCDISCがXML対応を完了する、のかも知れないが、すでにもうXMLでデータを表現するというのに問題も多くあるし。
もう、今時、ロケールとかフォントの設定で悩む時代じゃないと思うんだよなあ・・・・・・
Win7/VboxでFedoraでPythonでも、とかやっていると、悲しいことに、Windowsに最適化されてんだなあ社内LANは、と思うことに度々遭遇する。
しかし、もともと多分Linuxが抱えている闇として、Proxy設定がどーも一筋縄ではいかないというだけなのねということかも知れない。
pythonz+virtualenv+direnvとかで環境を作ろうとしてみたものの、pythonzでのインストールで、どうしてもProxyに阻まれているとしか思えない事象に何度も遭遇した。
そもそも、どんな開発言語でも使える統一したやり方としてのdirenvだけではどうしようもない気がしていたのだけど、そこら辺、pyenvだととにかくproxy通すことができるので、pyenvにする。
pyenvは先行して「zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl-devel」のインストールが必要ではあるが、そこはdnfで入れた。github.com
そのうちdefaultがpython3になるとは思うが。
しかもどーも一枚目がやられてたからっぽい。
結論を知ってしまうと、「なんだこんなことか」と思うのですが、原因究明には割と苦労しました。
障害分析って、ハード層からOS、アプリ層まで広くあるのでホントフックかけるだけの知識がいるなあ・・・・・・
余談ですが、近年のGoogleのこの手の技術情報検索能力が低下している気がします。
時事ネタにヒットしやすいんですが、技術情報にはヒットしづらいという。
考えようによったら、知識共有サービスがおいしい状況ではあるんですが、うーん、Googleの検索エンジンにその手のオプションがほしいだけなんですがねえ。
日本語の技術情報は、正直、「よく分からんが何となくクリアしてます」みたいな情報が多く、結論的にはかなり使えない情報にはなってます。
知識共有サービスも、基本的にはWiki形式の方が多分いいと思うんですよね。技術情報のWikipediaみたいな試みがなされるとよいと思います。
多分Adwordsとかじゃなくてスポット広告みたいなので食えます。ランダム表示で雰囲気で表示させるような広告に比べて、どストレートにリンクを張る事もできるし、広告営業もしやすいんじゃないかなあ・・・・・・まあここは運営コストとかをペイできる、程度であり、爆発的にそれだけで儲けられる訳じゃないでしょうが、技術情報もストリーム的に流れてくとかITが売りの所がタブロイド化してWebの時事ネタひろう浅ましい状況にもなっているので、ここら辺ジャンル壊すような何かは出来そうとは思ってます。自分はやらないけど。余談の余談ですが、そろそろWebマガジンのクオリティペーパーを考えてもいい頃。
企業内認証つきProxy（ただし基本的には自動構成スクリプトでプロキシを決定）での事。
よく考えるとそりゃそうで、プロキシ設定を環境変数でやり切ると、そこへ影響させると通信に対して攻撃者がプロキシかませるという事にもなる訳で。
Fedora22からDNFになってる。yumより便利になったのかは正直分からん。ただひたすらプラグイン出てたのが整理されたのはいいことだなと。
yumと同じ書き方だけど、/etc/dnf/dnf.confに記述。
但し、ここでは、自動構成スクリプトでの設定方法は見つからず。dnfにプラグインあったら知らんけど。
自動構成スクリプトの設定には出来るが、当然ながらユーザやパスワードを記録する所はない。まあそうだろ。
色々な理由があるが。
もう何年目なんでしょうか。
UTF-8対応ですらロクなもんではないというか、文字操作下手なままだよね。
昔の素のSASがよい、という人にとってもUTF-8だと地獄なのですよこれが。
LinuxにSAS入れるとかあるんだけど、DMSがUTF-8をフルサポートしてないんだよなあ・・・・・・正直ツライ。
まあ、とりあえず1.7ベースなんでもうマズいだろと思うわけだけど、Oracleと提携して今後もサポートしていく予定っちゃ予定らしい。
らしいんだが、それってSAS全体でのコンポーネントがそれに縛られるという罠。
元々マニュアルすらナカナカ日本語化が遅い、んだけど、技術情報すらもあんまり見ずに提供してくれたりする。
多分技術資源も枯渇してる。
元々頓珍漢な回答をしてくる事もあったんだけど、SAS Note検索で終わってしまっている所がなんとも頼りない。
デグレも起こすし、製品としての質も上がらんし、ビジュアライゼーションには微妙だし、サーバ製品ばかり売りつけようとするし。
まあ、あと、統計解析のアプリは、各種データを引っ張りだした後に「手元で」解析したい事が多い訳で、ここら辺、客のニーズに答えてない感じがスゴイんだよなー。
あと、確かに出来るとスキルにはなるよ。なるんだけどさ、スキルが必要過ぎる言語ってのもちと違うんじゃないかとは思う。
メモ書き。
大変残念なお話ではある。
本質的に単なるテキストファイルなのでどうしようもないSASプログラムの問題はおいておくとしても。
非互換なのが、SASカタログ形式も含まれるのが地味に痛い。
FORMATやMACROなどをふっつーにぶち込んだのが悪いと言えば悪い。たまにPNGなどの画像ファイルも入る訳だが。
これ、大変出来が悪いというか何というか。非互換の壁が単に32bitと64bitで壁になってしまう。何で？とは真剣に思う。
元々バイト長指定での定義っつーのも悪いんだが（悪い事バッカリだなあ）、想定文字数×３倍を想定する必要があるのが、S-JISの場合の２倍に比べてイメージもしにくいし大変。
無駄に長いしなあ。32767バイト→おおよそ一万字が最大長というのも、正直どうなんだという気はする。
データセット名も変数名もSASNameでお願いします。だが、ここら辺の区切りを勝手にSASが拡張し、SAS謹製のものでは平気でぶち込んでくるのが仕方ないのは仕方ないが。
治験関連では一切見たことないが、BIでの分析では平気でその手のデータセットを作って来る。
使い勝手も悪かろうに、とは思うのだが、それ以上に問題になるのが、「この手の非ASCII文字も移行の壁になる」という所。
化けますしラベルはよく切れます。はい。
これも大変厄介で、単にバージョンを上げたい・bit数を変えたプラットフォームで、というような話でも、移行期間が契約上の期間に縛られる。無論、32bit環境がなくなれば、非互換のものをどうにかテキスト抜く（フォーマットカタログならデータセットに抜ける）事が出来なくなる。
テクニカルサポートの話じゃなくて。
クロスプラットフォームと言いながら非互換がかなりあるとか、資産移行に関して元の環境から抽出することが必要とか、まあ、結構コアな次元からコンピュータ知っていて初めてピンと来るような話が沢山ある。
これ、2000年代に遭遇してたら、まだ客に理解してもらいやすかったんだが、今だとIT化第一世代の人が退職してたりする為、顧客企業にノウハウ持ってる人も減ってる。
説明するのがホント面倒なんだよね。「当たり前に出来るでしょ？」みたいに思われてるから。
ちっと前まではOSがx64化してもOfficeは32bit版というのが結構あったのよ。Officeの64bit版でいくつも障害があったりして。
あ、Officeも32bitと64bitではコンパイル済みのVBAがbitに影響されたりして最悪だったなあ。
この、bit数の違いを対応するのに、「bit数の違いがある場合には、PC File Server経由アクセスで」「そうでない場合には今までどおり」という風にコードが分かれた（機能的にも分割された）という所がまた厄介。
何かxlsxエンジンとかも追加されたけどねえ。
コード側で細かく条件つけて連携したりインポートしたりエクスポートシたり出来ないので（ここの機能制限が本当に腹立たしいのだけど、変数の自動作成＋自動判定をACEエンジンに任せている都合もあって、SASのバグではなくOfficeの機能制限だったりする）、SAS/ACCESS Interface to PC Filesはナカナカ簡単な機能ではなくなってしまってる。
ま、EGに実装されているExcelインポートも、実際の所.net側で特殊区切り文字のテキストファイルにしてからサーバ側で読み書き実行しているので、最早SASから直接Excel読み書きする「べきでない」のかも知れない。
ああ、もう、64bitでも互換性の為に32bitエンジン積んでいるとかでもいいのでそうしておいてほしいなあとは思う。ライセンス料２倍とかは要らんでしょ？
ill-identified.hatenablog.com
で言及されました。うん、TBやっぱあった方がいいよね、はてなブログ。
まあそれはともかくとして。
SASv8ではエラーになったり出力時にバグが発生したりしました。SAS9になっても残ってる部分はあると思います。SAS9.4ではどうなってるかまでは把握してないですが、SAS9.4ではODSの周りでデグレ起こっている可能性が（デグレではないかも知れないが、UTF-8周りでのフォントの扱いに何かしら難点がある）あるのもあって、まだ完全には対応し切れていない可能性があります。
DBCSLANGとかは起動後には変更出来ません。利用するSASHELPとかが完全に違ってくるとかあるので。多分MEMSIZEとか、XCMDとかもです。
「OPTIONSステートメント」「SAS システムオプションウィンドウ」と記載されていない場合には、起動後の変更は無理です。
多分SASonDemandは今のSAS Integration Technologiesベースでしょうし、マルチなエンコードは想定されてないので無理です。
1つは, 何らかの理由で, sas7bdat から文字コード情報が欠落しているため文字化けが起こる場合, もう1つは, 変換後の文字列のバイト数が文字変数の長さを超えてしまうため文字列の切り捨てが起こる場合である.
1つ目の, 文字コード情報が欠落している場合は, 対処が簡単で, テキストファイルのときと同様に, 文字コードを指定するオプションを使う. これには2つ方法があり, 1つは libname ステートメントに inencoding= オプションを使うことでライブラリのデータセットに一括で指定する方法で, もう1つはデータセットオプションの encoding= を使う方法がある (Technical Support, SAS(R) 9.2 National Language Support (NLS): Reference Guide).また, これらはどうやら v9 以降でしか使えないようなので注意. 具体的には, こういうようなコードになる.
SASでの文字コードの扱い方 - ill-identified diary
UTF-8環境だと「Default」、S-JISなどだと「S-JIS」と表記されてしまうSASデータセットですが、実際に存在します。
で、この何らかの理由なんですが、微妙に思い出して来たのですが、「.sas7bdat」で表現されるこのデータセット、上位互換とは言いながら、v8の時代には「エンコーディング」の情報はなかったっぽいです。
参考：
英語版SASで作成したSASデータセットを編集モードで開けない
道理でやたらあると思った。日本でのSASの普及から考えるとv6からv7をスキップしてv8.2とかだったんで、このv8.2辺りで作成されるとエンコーディング情報がないんですね。
もう一つ。XPORTファイルを作成する場合には、エンコーディング情報が同様にすっ飛びます。.sas7bdatではないですが。
少しでも無駄な悩みが減りますように。
こういうトラブルって、人を渡り歩くと本当に大袈裟な話になってくからなあ・・・・・・。
SASサーバに紐付ける形でのEGの設定なのにプロファイルを使わないローカルの設定になっていないかどうかとか確認しておいてほしいです。
SASのトラブルのあるあるネタとして、「ライセンスが切れてる」って場合多々あるので、ライセンスはご注意を。以前は実行出来たのに！とかの場合かなりの確率でコレです。
一年間しかライセンスがないっての本当に面倒臭いです。
SASの嫌な所なんですが、「ライセンス上使えないんだけど口だけはある」とかの場合に、平気でエラーとかにするんですよね。あと、使えないオプションのパターンがあるとか。
まあエラーまでは許すとしても、前調査用スクリプトみたいなの組み込んでおいてくれてもいいと思うんですよ、本当に。
あと、ソースのフォークが怖いのかも知らんけど、DMSはともかくとして、EGのローカルとリモートサーバ用、パッケージとして分けてもバチ当たらんと思うんだよねえ・・・・・・。
お客さんの少ない情報から環境を推し量る技術だけが妙に向上していくのはホントどうにかなんないですかね。
SSDが安定するのですが。Fusion-IOとかの大容量SSDも出てますし、256GBでも問題ないですし。
メモリだと、大容量メモリに個人用PCだとそれほど対応していないというのもあります。家のマシンだとほぼ16GB積んでいるんですが、これから上になるとレアモノだったりノートPCに刺さらなかったりでして。本当は64GB積みたいです。
MEMLIBシステムオプションをconfigファイルに記述する事で、WORKライブラリをメモリ上に乗っける事が出来ます。
当然ながら、以下のメリットがあります。
デメリットは、「利用ユーザがメモリページをロックする権限を追加しなければいけない」（ローカルセキュリティポリシーの修正）のと「UAC無効化が必要」なのと、まあ、そうやってメモリを使うと当然ながら起動プロセス毎にメモリがその分減ります。
（参考：18274 - When you use the MEMCACHE or MEMLIB system options the following error message occurs "Error: Cannot adjust the token privileges with error 1300."
強制終了後WORKライブラリの中身調査とかはまずしないので消えるのはいいんですが。
この点、特に速度が重要な場合のみ、異なるConfigで実行するような事を想定した方が良いかと思います。あと、この場合プロセス強制終了時にメモリ解放されんのかとか気になりますね。やっぱ別のRAMDISKアプリを使った方が幸せになれそうです。
-config "C:\Program Files\SASHome\SASFoundation\9.4\nls\ja\sasv9.cfg" -MEMLIB -MEMCACHE 4 -MEMMAXSZ 500M
そう言わざるを得ない。
「解析」がつくと怯む人も出て来るが、実際の所、大した調査もせず、国家統計で出て来ている数字を適当に組み合わせて「分析」と言う人が多い。
これはホント不思議なんだけど、「機構は隠されているが」「統計上で見える関係に近い事で物事が動いているんだ」と思う人は多い。
統計モデルの適応例として、情けない事に、SEのステップ数計算とかがある。ロクに当たらず、勘の拠り所にもなりづらい。
よく疫学として水俣病の話が上がるが、稀な例であり、多くは「はっきりしない事がはっきりする」という冗長な話になる。
もう、「悪用厳禁」とか書いておいたらいいと思う。
VMのテンプレートで提供とか酷えです。
SAS Studioが悪い、って気はしないですが、
大した工夫もなくただプログラムをWeb経由で登録実行出来はするんだけどさ、
ライセンス料金はともかくとして、どう考えたってシンプルに生SAS使うのに比べてCPUやメモリを無駄食いする。パフォーマンス・チューニングもロクに出来ないしな。
今のSAS、CentOSにだって入れられる（残念ながらDebian系にはそのまんまは入れられない）んだけどさ。
いい加減マルチコア対応とかのちゃんと使いたい訳ですよ。潤沢なメモリ活かして。なのに、何故Webサーバ（裏でJava）の為にメモリ使うんだよ。そんなマルチユーザ向けの機能とかいらないしー。
もう少しSASはエンジンとして使い勝手を良くするべきなのに、うざったいなあ。
大学で利用している人は、大学で購入しているパターンが多いので（Universityのライセンスとかで）、もう少し活用してやるといいんじゃないでしょうか。
University Editionを企業で利用するのは多分宜しくないし、頭も悪い感じになると思います。
という事を延々と言っているのだけどなあ。
某所にて。
設計書作りと設計が乖離し、開発と開発すべき物が乖離し、お客さんと合意すべきものが散逸し、どこから手を付けるか→卓袱台返しやった方が早いだろう、とは常々思っているのだが。
まあ2月ぐらいから言っているので、結局の所、順調に終わっているのだけど。
昨今の開発において、完全なるウォーターフォールは難しい。
予測不能の開発困難点が発生した時に、要件の方から手をいれる必要があったりするのだが（ここら辺、キッチリ顧客業務要件と機能要件を意識的に分けて考えるべきなのだが、顧客は時々勘違いして要件を飛び越えて機能やUIを要求するし、設計者は業務要件を意識しない事がある）、
ともかくも、関係者全員が無能力状態である。
自分も、開発についての権限は持ち合わせていないしなあ。なんかねえ。
責任取れと言われる事はないだろうが、自分が東京で働いていたらとうの昔に転職してるわーという状況なんだが、それでも自分を常駐させようとか言うんだろうか。
言うんだろうかなあ。
前の担当課長は転職したし、先輩も転職したし、その状況であるという意味分かってんのかねえ。
期待は薄いなあ。
ホント応募しようかしらん。
まあ、でも、歌って踊れてというタイプのSEなので、スペシャリスト的なものではないんですが。
タイトル通り。
いわゆるISO-8859-1、通称Latin-1というヤツであるが、これ、Windows上では拡張されWindows-1252というものになっている。
この拡張された部分に埋められた文字が、UTF-8では3バイトになるものがある。ダガーやダブルダガーとか。
shift_JISからだと、2バイト→最大4バイトでありcvpmultは2で十分なのだが、wlatin-1だとこれがcvpmult=3を設定しなければいけない。
大変残念である。
本来はlatin-1はUTF-8でも文字としてのバイトの中身が変わらんのだけど。大変残念である。
追加：latin-1かつ非ASCIIの場合には、UTF-8と解釈しようとしても上手くいかない。
