変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

インターネット

名前

子供に変な名前を付けてしまうと
後で変えるのは、とても大変ですが・・・
プログラムの変数やデータベースのテーブル名は簡単に変えられます。
但し、それを使っているプログラムがいっぱいあったら、
これらを書き換えるのは非常に困難です。
適当に変数 a  b  c   d と付けたあと
vTop  iLow  dtNext   tmStart
なんてのにしようとしても、変換ツールで一発で・・・とはいきません。
ソースに    abcd と書いてあると  vTop iLowdtNexttmStart に変換されてしまいます。
SQLのテーブル名が a b c d だったりしたら・・・どっと汗が出そうです。
英字は i  や e  は頻度が著しく高いので、int i なんかは特に悲惨です。
C言語的には、int i,j,k の頻度は異常です。
また安易に文法を見て変換しようにも
a=b や  a = b とか書き方で変換しにくくなり、
更に、特定の巨大な関数の一部なら ともかく 特定の巨大な関数全般に分散していたら、どうすることもできません。
言語によっては、
int a;
function a(int a) {

{

int  a;

{

int a;

}

}

}
このaたちは全て別人ですから、特に厄介です。
ただひたすらに手で治すしかないのです。
リファクタリング・ツールも、日常的に使う用途のもので、
動作が緩慢ですし、時には失敗もしでかすので、入念なチェックが必要、趣味用のツールなので・・・
ですから、変数名が気に入らないから一斉に直せ!なんて用途には向いていません。
 
 
つまり、この手ことは問題は解決策は人手しかないわけです。
 
そんなことは・・・大昔のIBMの360の苦労本にも出てるんじゃないのかな?
 
そんな訳で設計期間って結構長かったりするのは、こうならないための重要な期間だったりするのですが・・・
大抵は、
 
そんなの後で治せばいいよ
 
 

いつものように

 
ですよね~(大笑
 
本当に必要なツールは、
どんなに汚くい仕様書やソースでも
自動的に綺麗に清書してくれる
そんな開発ツールじゃないんでしょうか?
そのためのリポジトリだったハズなのにね!(大笑



今の状況

旧マシンを全部止め、新マシンだけ起動したら・・・
部屋がとっても静かになった。
NUCも大量のファイル転送でもしない限り無音。
この記事を書いていてもさほど負担にはならないようですね。
初期のAtomとはえらい違いです。(笑
ゲーム用のパソも廃スペックだけど、ファンコン絞れはほぼ無音です。
 
店員が滑らかに動くゲームのデモを見せながらi3の方を勧めてましたが、
使い道がBlog用なので安物のCeleronNUC(DCCP847DYE)にしました。
メモリも1枚です。SSDは30GBにしたかったのですが品切れで60GB。
現在8GBちょっとですから、後10年は使えそうです。
ケースの色はアニメの舗装のアスファルトの色みたいなダークグレイ。
そんな訳でチョロQを載せてみました。
※タバコは大きさ比較のための障害物です。
DCCP847DYE_3
マザボが上下逆(天井側に付いている)なのでLANコネクタが逆さまです。
DCCP847DYE_1
オマケに釣られた訳ではありません。
袋の後ろが旧BLOG鯖。(でも、見えませんね。
電動チョロQの充電台に偽装も可能です。
DCCP847DYE_5 
無線LAN仕様で電源ケーブルのみのBLOG鯖
1日のHit数が300と少ないので、ほぼ待機電力で運用可能?
DCCP847DYE_2
やはり、ワットチェッカーが欲しいですね。
台になっているのは戦車PCケースです。



無線LAN接続

NUCでPCIデバイスはどうなっているのか?

# lspci

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)

00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)

00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)

00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)

00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)

00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)

00:1f.0 ISA bridge: Intel Corporation QS77 Express Chipset LPC Controller (rev 04)

00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)

00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)

02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)

となっていた。
Gigabit Network は無線ではないだろうから、
Intel Corporation Centrino Advanced-N 6235
が無線LANボードらしい。認識しているので、どこからかドライバーをダウンロードしてカーネルに入れる必要はないようだ。
まず、デスクトップで作ったkeyファイルは削除。
ifcfg-wlan0は、

DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=no
TYPE=Wireless

に変更。
※この時点でデスクトップは無用になった。
ONBOOT=no
なのに
BOOTPROTO=dhcp
って変だけど、削ると、最後の方で ifup wlan0 が空振りしてしまうので必須。
※BOOT時にシェルのドコかで使うコマンドなんだろうなぁ~
では、WPA2だけのために、無線LANで認証するためのサービス(WPA  wpa_supplicant) をインスト。

# yum -y install wpa_supplicant

/etc/sysconfig/wpa_supplicant が出来ていたので、
3行目を INTERFACES=”-iwaln0“ に 6行目を DRIVERS=”-Dwext” を変更。
次は設定ファイルの更新だ。

wpa_passphrase {SSID}  {パスワード}

network={
ssid=”{SSID}”
#psk=”{パスワード}”
psk={パスワードを暗号化した意味不明な長い文字列}
}

と、それっぽいテキストができるので、
#  wpa_passphrase {SSID}  {パスワード}  >> /etc/wpa_supplicant/wpa_supplicant.conf
で設定ファイルに追記し、wpa_supplicant.confを開き、
ssid=”{SSID}”の後に ココココを見ると、WPA2なら

proto=WPA2
key_mgmt=WPA-PSK
proto=WPA WPA2
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40

を追記するといいらしい。
では繋いでみましょうか・・・

service wpa_supplicant start

wpa_supplicant の起動中: /etc/wpa_supplicant/wpa_supplicant[  OK  ]iwlan0、-Dwext

結果はどうなんだろう?

# ifconfig

wlan0 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet6 addr: ****::****:****:****:****/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10157 (9.9 KiB) TX bytes:1011 (1011.0 b)

IPアドレスが取れていないので、
フム失敗のようだね。
色々設定を繰り返しいるうちにdmesgが

ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with **:**:**:**:**:**
wlan0: send auth to **:**:**:**:**:** (try 1/3)
wlan0: send auth to **:**:**:**:**:** (try 2/3)
wlan0: authenticated
wlan0: associate with **:**:**:**:**:** (try 1/3)
wlan0: RX AssocResp from **:**:**:**:**:** (capab=0x*** status=* aid=*)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

と良さげな内容になってきたが、
ルータの方を見ても、

MACアドレス リースIPアドレス ホスト名 通信方式 無線認証 802.11n
**:**:**:**:**:** 無線 認証済み 有効

なんでIPアドレスもらいにいかないのかな?

# dhclient

# ifconfig waln0

wlan0 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:**.**.**.** Bcast:**.**.**.** Mask:255.255.255.0
inet6 addr: ****::****:**:**:**/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:514 errors:0 dropped:0 overruns:0 frame:0
TX packets:136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:156326 (152.6 KiB) TX bytes:19058 (18.6 KiB)

なんてこった。(笑

/etc/rc.d/rc.local の最後に

ifup wlan0

を追記し、起動時にIPアドレスを聞くように云っておく。
使用しているルータ( WHR-G301N )のDHCPには珍しいことに手動割当ができる。
ルータからNIC指定で同じIPアドレスを割り当てられるので、NUC側はDHCPのまま。
NUC側で固定にしたい場合は、
ifcfg-wlan0の
BOOTPROTO=dhcpを
BOOTPROTO=static IPADDR=192.168.***.*** とすればいいだろう。

※今は、こうなっている。
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=no
TYPE=Wireless

/etc/rc.d/init.d の下のchkconfig用設定ファイルの書いてある、起動順序を入れ替えれば /etc/rc.d/rc.local で ifup wlan0 しなくてもよいようだ。
# for  a     in   * ; grep chkconfig $a; done
・・・
# chkconfig: – 23 88
・・・
# chkconfig: 2345 10 90
っといっぱい出てきた。
左から2つ目の数字が起動順だ。
# grep chkconfig   wpa_supplicant
# chkconfig:23 88
# grep chkconfig   network
# chkconfig: 2345 10 90

なので、wpa_supplicantの方を9に変えてしまえばいいようだ。(超いい加減。
しかし、結果から云えば、ダメだった。ずーっと23番目。
※後でみてみたら20番にいたり・・・不安定

こうなったら

最終手段

/etc/rc.d/init.d/wpa_supplicant の

最後に
ifup wlan0
を入れた。

後悔するだろうなぁ~忘れた頃に・・・
ps 修正箇所を見つけるのに苦労したので、文面を一部訂正。(笑



新BLOG鯖の構築

構築手順はこんな感じになる。
参考: CentOSで自宅サーバー構築

  1. ネットワーク・インストーラの準備
    • syslinuxをダウンロード。
    • USBメモリにブートローダをインスト。
    • CentOS6.4のネットワークインストール.ISOをダウンロード。
    • ISOファイルを展開し、isolinuxフォルダの中身をUSBメモリにコピー。
    • isolinux.cfg を syslinux.cfg の名前でコピー。※おまじない
  2. CentOS6.4 最小限インストール
    • NUCの電源を入れ、すぐに{F2}を押して、UEFI(通称BIOS)を起動。
    • BOOTデバイスの一番上にUSBメモリを移動。
    • exit⇒保存を選択し、再起動。
      • Boot: の後に Linux {ENTER} と入力して起動。
    • 以下、ココの通りに進める。
      • 後で無線LANに切り替えるのでIPアドレスはそのまま。
  3. CentOS6初期設定
    • (2)一般ユーザの作成&削除
      • ※監視メール受信用アカウント
    • (5)パッケージ管理システム設定
    • (6)root宛メールを転送する
      • /etc/aliasesの変更。
        • rootを監視メール受信用アカウントに転送。
    • (7)SELinuxの無効化
    • (9)nkfコマンドインストール
    • reboot
  4. 無線LAN設定
  5. ファイル改竄検知システム導入(Tripwire)
    • tripwire-2.4.2.2-src.tar.bz2 を使った
  6.  RPMforgeリポジトリ導入(RPMforge) ← 2016年7月20日頃から使用不可
    • yum-prioritiesプラグイン導入
    • 最新のrpmforge-release-0.5.3-1.el6.rf.x86_64.rpm を使った方が良かった気がした
    • EPELも導入
  7. rootkit検知ツール導入(chkrootkit)
    • 全部。
  8. アンチウィルスソフト導入(Clam AntiVirus)
    • /etc/rc.d/init.d/clamd start の 前に freshclam
  9. NTPサーバー構築(ntpd)
    • 全部。
  10. Webサーバー構築(Apache)
    • パッケージだけインスト。
  11. ファイアウォール構築(iptables)
    • 全部
    • LANケーブルを外してreboot。
    • LAN=wlan0
  12. Webサーバー間通信内容暗号化(Apache+mod_SSL)
  13. メールサーバー構築(Postfix+Dovecot)
  14. データベースサーバー構築(MySQL)
    1. 一応入ったが・・・
  15. MySQLデータベース自動バックアップ運用(mysqlhotcopy)
  16. MySQL用GUI設定ツール導入(phpMyAdmin)
    • パスがphpmyadminに変わってた。IPアドレスも違うので設定を変更。
  17. データファイル移行
    • あまりの分量にCeleronのファンが初めて回った。
  18. データベース移行
    • 圧縮を指定して移行
  19. ルータ切替
    • 完了。

 
 
 



新Blog鯖構想

何気にCentOS6.4を入れては消しを繰り返しているうちに
何が気に入らないのか判ってきた。
用途としては、

  1. apacheでWordPressを動かす。
    1. mysqlが必要。
      1. phpmyadminでも、チェックできるようにしたい。
    2. phpが必要。
  2. 24時間動きっぱなしになるので、
    1. 夜間yumパッチ
    2. 改ざんチェック
      1. ファイル改竄検知システム導入(Tripwire)
      2. rootkit検知ツール導入(chkrootkit)
      3. アンチウィルスソフト導入(Clam AntiVirus)
      4. ファイアウォール構築(iptables)
  3. 報告にメールサーバも必要。
    1. Postfix
    2. Dovecot

なダケなのに、いろいろ設定が必要だ。
今回一番面倒だったのが上に記載すらない無線LANの接続だった。
これもバックアップを取ったので、最小限インストールでも大丈夫だろう。※無線LAN接続パッケージが必要な気もするが・・・
 



ぷっつんしたので買ってしまった

嫌なことがあったのでDCCP847DYE NUC(Celeron版)を買った。
ケースはダークグレイ。いかにも安い感じ。
安いのを選択した理由は

夏を越えられそうな気がしなかった

からだ。(笑
しかし、一日中空回り(リブート放置)させたが、ほんのり温かい程度なので、
店頭ではCore i3の方で低解像度でゲームのデモを展示していたからオンゲの放置露店はできるだろう。
予算があればCore i3の方がいいだろう。
箱のCM音はセンサーか照明の角度のせいか、鳴らなかったり、3度鳴ったり不安定です。
※2~3度聞いたら、もう嫌になっていた。
合計で、NUCセット(ACコード込)+無線LANボード+DDR3(SO-DIMM) 13000×1枚+SSD 60GB=3.1万円
※メモリを1枚でもちゃんと動きました。
※Linuxを16GBのUSBにでもインストすれば、SSDもいらず設定が面倒な無線LANも買わなければ悩まず、お安くできたハズ。
今回は、INTELのSSD(30GB)は無かったので、PLEXTORの60GBにしました。
無線LANは店側が組込んだ状態でないと電波法違反らしいので組み込み待ち時間は15分ほどでした。
でも、組込み作業は無料でした。
次は高性能タイプのNUCが出たら、また試してみましょうかね。
勿論、無線LANも一緒に!
レベルアップして、組込み時間も短縮しているかもしれませんね?

 



NUC – YE (GBE LAN board D33217GKE )

NUC向けのヒートシンクなデザインのケース

このゴッツいカンジがいいよね。

店頭で展示してあったアビーのケースは触るとホッカホカな弁当箱な温かさだったが、これより冷えるのだろうか?
それともヒートシンクだけに熱っ熱つになるのだろうか?
平置きの方が冷えるらしくINTELのケースより10度ぐらい低い65℃ぐらいで安定するっぽい。

裏面がHDMI×2個タイプ専用なので、サンダーボルト付きタイプでは使えない。
Tranquil PC の価格は £99.00。
1ポンド 140.9547 円らしいので、1万4千円+輸送料かな?
日本ではオリオスペックがこのケースのBTOがあった。
 



EPRと量子ねじれ状態バンク間位相機能付リングバッファ

前回に量子メモリを通信媒体にするのはいいけど、いつかはメモリを使い果たすので物理的に交換するしかないことを述べた。いくらEPR通信が中継なしで通信できるとは云え、遠距離を大量の量子メモリを運搬するのはエコではない。
そこで今回は量子メモリをループにした量子リングバッファを使ってみよう。リングフバッファは、FIFO式にメモリをアクセスできるようにしたものからシフトレジスタで実直に実現しているものもある。
ここではバンキ切り替え式の疑似FIFO量子メモリを使ってみる。
単純に量子メモリの様に使えば、すぐにEPR通信のネタが尽きてしまうが、
バンク切り替え時に空きバンクの量子ねじれ状態を別の空きバンクと量子演算して、量子ねじれ状態を位相してしまう機能をつけてしまうのがミソだ。
この機能のために常に2バンクが空きになっていなければいけないので勿体ないが、常に2バンクが相方と量子ねじれ状態にあるので、ずーーっと使える点が優れており、定期的に船でRPS通信専用の使い捨て量子メモリを運ぶ必要が無い特徴が素晴らしい。
だから、使い捨て(あるいはリサイクル型)EPR通信用量子メモリより廉価で通信できそうだ。
ただ、トランシーバー的な使い方ではネットサーフィンはできないので、やはり中央に交換機が必要だ。
全てのデバイスを直結で通信する疑似EPR通信は、量子ねじれ状態の一方を複製できないので、妄想上でも実現はむずかしいし、仮に実現してもいっぱいトラフィックが来たら今のサーバーでは処理しきれないのでINPUTもOUTPUTも無数のパターンを一度に処理できる超並列な量子コンピュータにしないといけないのでかなり遠い未来の話になってしまう。
 



カーソル

MySQLのサンプル 参考URL: http://dev.mysql.com/doc/refman/5.1/ja/stored-procedure-syntax.html

CREATE PROCEDURE curdemo()
BEGIN
  DECLARE done INT DEFAULT 0;
  DECLARE a CHAR(16);
  DECLARE b,c INT;
  DECLARE cur1 CURSOR FOR SELECT id,data FROM test.t1;
  DECLARE cur2 CURSOR FOR SELECT i FROM test.t2;
  DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
  OPEN cur1;
  OPEN cur2;
  REPEAT
    FETCH cur1 INTO a, b;
    FETCH cur2 INTO c;
    IF NOT done THEN
       IF b < c THEN
          INSERT INTO test.t3 VALUES (a,b);
       ELSE
          INSERT INTO test.t3 VALUES (a,c);
       END IF;
    END IF;
  UNTIL done END REPEAT;
  CLOSE cur1;
  CLOSE cur2;
END 

ORACLEのサンプル 参考URL http://www.shift-the-oracle.com/plsql/

CREATE OR REPLACE PROCEDURE RIVUS.STEP01_SELECT2(P_DATA_1 IN VARCHAR2)
IS
	CURSOR cDual(P_DATA_2 VARCHAR2 := 'CURSOR param') IS
		SELECT P_DATA_1 COLNAME_1 FROM DUAL
		UNION ALL SELECT P_DATA_2 COLNAME_1 FROM DUAL ;
BEGIN
	FOR vRec IN cDual('xxx') LOOP
		DBMS_OUTPUT.PUT(cDual%ROWCOUNT || ':');
		DBMS_OUTPUT.PUT_LINE(vRec.COLNAME_1);
	END LOOP;
END;
/

同じカーソルでも書き方が全然違うそれがSQL。
似てると云えば、変数宣言はBASIC風なDECLARE文。
何か失敗した場合は、
BEGIN
・・・何か
EXCEPTION WHEN OTHERS THEN
— 画面出力
DBMS_OUTPUT.PUT_LINE(‘エラッた’ || ORA’ || SQLCODE || ‘:’ || SQLERRM);
— ログ出力 error_logs テーブルに書き出す
SIMPLE_LOGGER(SQLCODE, ‘INSERT ERROR’);
END;
/
 
IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
・・・
と自動でやってしまう手もあるらしいが更新した後にcommitしないと自動的に・・・
 



Node.js を少し勉強してみた

ここにビギナー向けの記事がある。
単純にサーバーサイドの処理を突っ込むと、ドコかで長い処理があれば、他のリクエストは待ちぼうけになるようだ。つまり、Windows 3.xのようなノンプリエンティブな作りになっているのだ。
apacheみたいリクエストを一個づつスレッド化すれば、サーバーサイドの処理はリクエストごとに独立しソースに書いた通りに綺麗に動くハズだが、同時接続が500くらいになる(つまり同時に存在するスレッドが500を越えると)と、多数のHDDアクセスやらDBアクセスが同時処理となり大混乱になるのは容易に予想でき、ノタノタになるのは目に浮かぶ。apacheを使うなら同時接続数が際限なく増えないようにサーバーサイドの処理は手短に短時間で終わるように作らないといけない。
TomCatはapacheの様にプリエンティブでマルチスレッドだから同時接続数が増えればやっぱりノタノタになるだろう。
一方、ノンプリエンティブなら手短な処理だったら、他の要求はそのままちょっと待たておいて、そのまま処理を実行すれば、リクエストは順次処理されるのでHDDアクセスやらDBアクセスは同時接続するのは1セッションのみのハズで、結果として乱雑なNASや他のサーバーへのアクセスが減り全体としてのパフォーマンスが上がる可能性が出てくる。
仮に同時接続100ぐらいまでなら十分な性能が発揮できる高価なDBサーバーだったら、node server.js をポートを別けて100プロセス実行し、オートバランサーでリクエストを公平にばらまけば、高価なDBサーバーの性能を100%発揮できるだろう。
そして、本当に重い処理(膨大なレコードを参照する年次処理とか、1000ページを越えるPDFファイル作成など)の場合だけ、子プロセスを作り、できればサーバーも別にすればシステムの過負荷時のリスクも相当減ってくる訳だ。
ま、今あるNode.jsをベースにした色んなパッケージがそのように出来ているのかは判らないが、泥臭いチューニングをそのままベタ書きできそうで心強い。
apacheのことを悪く書いてしまった様な気もするが、WEBのフロントエンド、そしてオートバランサーとしてのapacheは使い道がある。TomCatだって裏側で重い処理専用のアプリケーション・サーバーとして利用する分には十分に使えるだろう。
そんな訳で、その中にPHPには不向きで、TOMCATには荷が重すぎる様なサービスをNode.jsで作っていくのは悪いアイデアではない気がする。
多分、一番良くないのは、Node.jsがあれば、apacheもPHPもTomCatも要らないとか言い出すコトだろう。
まずapacheのゴチャゴチャな設定ファイルをNode.jsで作ったポータル用に解析しコンバータを作らないといけないし、本当に要求仕様を満たしているのかわからない大量のPHPやJavaServletのソースを延々とjsに書き直してみたら高価なサーバーだったからコレでも動いていたのか?な、つまらない結果を見ることになるだろう。
※このBlog鯖のapacheの設定ですら結構ゴチャっているだ。
所詮jsの速度が数倍から数+倍になってもネイティブなコードとの差は絶対的である。
さらに簡単なコードだからこそ、GCの性能も十分に出ると考えていいだろう。重厚長大なjsファイルなぞ起動するだけでも使用メモリが恐ろしいコトになる気がする。
 
例えば、身近な例として、
クライアントのIDEとしては普通なフルセットのEclipse IDEをそのまんまサーバーサイドなNode.jsに移植したらどうなるだろう?
プロジェクト全員が使っているIDEであるから、プラグインの入れ替えは深夜作業になるだろう。
どう考えても面倒でも各自のパソコンにIDEを入れて試行錯誤して貰った方が楽に違いない。
例え誰かがパソのIDEをクラッシュさせても、その誰か以外は被害を受けないから・・・プリエンティブな開発環境ですね!
そう考えると、パソコンにインスト不要なNode.jsなサーバーでサーバーサイドなIDE(統合開発環境)とは、開発環境全体がノンプリエティブ化され、たった一つのプラグインのミスもお手上げ状態になりそう。
かなり運用が難しく、色々問題を抱えそうである。
単純にapacheをフロントエンドにしてNode.js なIDEを設定ファイルで切り替えてリロードさせる様な運用をするだけでもかなり現場の雰囲気は違ってくるだろう。
そこが混在させる良さである。
全部Node.jsで作れば、そんなスイッチすら作る考えすら起きずIDEを直結で利用になるだろうね。後で後悔してスイッチ付けるだろうけど・・・
そうならないクラウド(使用も運用もお手軽)なサーバーサイドIDEがあればいいんだけどね。(笑




top