アカウント名:
パスワード:
なんかフツーvs開発者の比率って1000:1程度の様な気が・・・・
ソフトウェアのプログラミングについては、88％のユーザーが行っていると回答し、そのうち46％のユーザーが仕事・趣味両方でプログラミングを行っている
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
日本の開発者が増えるには (スコア:0)
とあるVB房がLinux開発環境に抱いているイメージ (スコア:2, 興味深い)
2.VBみたいに簡単にGUI作れるの？
VC++未満のWin32API叩くような感じな気がするけど・・・
そういえば、Kylixとか聞いたけど使えるようにするのは簡単？
3.KDEとGnome、gtkとかqtって何？
そもそも違っても別のLinux環境でも動くの？
4.理想は言語内ですべて済めばいいけど、そうはいかないし。
さて、日本語のAPIドキュメントってあるのか？
MSDNレベルの整理されたドキュメントは欲しいなぁ。
開発環境に統合されてれば最高！
5.IME(FEP)の制御って簡単に出来るかな？
まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
手動で送信とかいう冗談みたいな事はないよね？
6.文字コード意識しないといけないの面倒。
EUCかUnicodeかなんでもいいから統一してくれ。
7.このプログラムは将来的にも一応動くの？
今作ったプログラム、とりあえず5年は動くかなぁ？
ランタイムのバージョンが新しくなって動かなくなって、
ヘルプで時間取られるの嫌だしなぁ。
8.インストーラー簡単に作れないかなぁ？
rpmやdebを自動的に構築。
必要ライブラリもインストールor警告出すようにとか。
スタートメニュー(というかランチャ？)に登録もしてくれよ～
9.このショートカットキーの組み合わせ、
この環境だとOKだけど、別の環境でも使えるんだろうか？
10.そもそも、日本語文字列の処理うまくいくのかな？
左から何文字目とかやったら、
左から何バイトに解釈されてへんな所で切れないだろうなぁ？
とか色々書いてみましたが現状どうなっているやら・・・
あと、言語と環境がごっちゃになっててすいません。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:2, 参考になる)
> 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。
あることはあるのですが、古いものばかりですね。
KDE/Qtは2.xから大きくは変わってないので、それなりに使えますが。
> 2.VBみたいに簡単にGUI作れるの？
> VC++未満のWin32API叩くような感じな気がするけど・・・
Qtに関して言えば、Qt Designer [trolltech.com]があるので楽です。
> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
> さて、日本語のAPIドキュメントってあるのか？
> MSDNレベルの整理されたドキュメントは欲しいなぁ。
> 開発環境に統合されてれば最高！
英語なら充実してるのですが…orz
開発環境との統合については、一応KDevelopからリファレンスが見れたり、
Qtのクラス名を選択して検索などが出来ます(KDEのクラス検索はうまくいかなかった)。
> 6.文字コード意識しないといけないの面倒。
> EUCかUnicodeかなんでもいいから統一してくれ。
Qtの場合内部がUnicodeなので、コードに直接EUCで書く場合は変換する必要があるくらいかな(QString::fromLocal8Bit())。
ファイル入出力はデフォルトで設定されているロケールを利用するのでたぶんOK。
> 7.このプログラムは将来的にも一応動くの？
> 今作ったプログラム、とりあえず5年は動くかなぁ？
> ランタイムのバージョンが新しくなって動かなくなって、
> ヘルプで時間取られるの嫌だしなぁ。
同じメジャーバージョンならバイナリ互換性あったような気がするけど細かい所は忘れた。(3.1.xと3.2.xって互換性あったっけ)
まあ、static linkすれば大丈夫かと。
# ライセンスの話はここでは略。
> 8.インストーラー簡単に作れないかなぁ？
> rpmやdebを自動的に構築。
KDevelopには*.spec作成用のダイアログがあります。
動作が怪しいので使ってないですが(^^;)
> 必要ライブラリもインストールor警告出すようにとか。
rpmの機能ですね。必要ライブラリの依存関係はrpm4から自動チェックしてくれたはず。
> スタートメニュー(というかランチャ？)に登録もしてくれよ～
KDevelopで新規にプロジェクトを作成するとメニューへ登録するためのファイルも作ってくれるはず。
> 10.そもそも、日本語文字列の処理うまくいくのかな？
> 左から何文字目とかやったら、
> 左から何バイトに解釈されてへんな所で切れないだろうなぁ？
そういう酷いのはまずないです。
Unicode ←→ "Shift_JIS"のマッピングとか、フォント関連とか、地雷源は大量にありますが…。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1, 参考になる)
> 1.開発HowToが書かれた日本語の書籍は少ない・・・気がする。
VB 等に比べるまでもなく、実際に少ないと思います。
Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。
> 2.VBみたいに簡単にGUI作れるの？
> VC++未満のWin32API叩くような感じな気がするけど・・・
> そういえば、Kylixとか聞いたけど使えるようにするのは簡単？
kylix を使えるようにするのは、単にインストールするだけなので簡単でしょう。
フリーの UI ビルダも、 GTK 向けの glade があります。
Qt 向けのは知らないので、詳しい人のフォローを希望。
> 3.KDEとGnome、gtkとかqtって何？
> そもそも違っても別のLinux環境でも動くの？
KDE と gnome は、デスクトップ環境の名前です。
gtk と Qt は、 GUI を提供するライブラリの名前です。
使うライブラリさえ揃えれば、ディストリビューションが異なっても動くでしょう。
ライブラリを揃えさせるのが面倒なら、 statically linked なバイナリにすれば、何も考えずに動かせるでしょう。
> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
> さて、日本語のAPIドキュメントってあるのか？
> MSDNレベルの整理されたドキュメントは欲しいなぁ。
> 開発環境に統合されてれば最高！
MSDN のように一枚岩のドキュメントはありません。
各ライブラリの API リファレンスも、新しいものは日本語に翻訳されていなかったりします。
> 5.IME(FEP)の制御って簡単に出来るかな？
Input Method 周りは鬼門です。
最近の gtk immodule なら、だいぶ楽になってきてはいるようですが、詳しいことは分かりません。
フォロー希望。
> まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
> 手動で送信とかいう冗談みたいな事はないよね？
日本語としてパースできませんでした。
> 6.文字コード意識しないといけないの面倒。
> EUCかUnicodeかなんでもいいから統一してくれ。
プログラム内部コードは、 4 byte の wchar_t で統一されています。
最近では、インストール直後からロケールが適切に設定されるので、外部コードが EUC であっても UTF-8 であっても、 (多分) 悩む必要はありません。
> 7.このプログラムは将来的にも一応動くの？
> 今作ったプログラム、とりあえず5年は動くかなぁ？
> ランタイムのバージョンが新しくなって動かなくなって、
> ヘルプで時間取られるの嫌だしなぁ。
難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
# 5 年後に X が無くなっていると無理ですが…。
この辺は、 VB でも同じような物じゃないかな。
> 8.インストーラー簡単に作れないかなぁ？
> rpmやdebを自動的に構築。
> 必要ライブラリもインストールor警告出すようにとか。
> スタートメニュー(というかランチャ？)に登録もしてくれよ～
一定のルールに従ったソースコードなら、 deb はコマンド一発で作れて、ライブラリの依存関係も勝手に計算されます。
rpm は良く知りませんが、似たような仕組みはあるのではないかと。
メニューへの登録も、いくつかの簡単なテキストファイルを用意するだけです。
> 9.このショートカットキーの組み合わせ、
> この環境だとOKだけど、別の環境でも使えるんだろうか？
微妙です。この辺りは、 95 以降の Windows の方が統一されているでしょう。
ある程度安全に使える組み合わせはあると思うのですが、詳しいことは分かりません。
> 10.そもそも、日本語文字列の処理うまくいくのかな？
> 左から何文字目とかやったら、
> 左から何バイトに解釈されてへんな所で切れないだろうなぁ？
最近は wchar_t があるので、日本語を扱う程度なら、意図的に変なことをしない限りは大丈夫です。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1, 興味深い)
>
> VB 等に比べるまでもなく、実際に少ないと思います。
> Web のリファレンス/チュートリアルでは不満な人には、厳しいかも知れません。
手元にKDEの本が3冊、Qtの本が1冊あります。入門用には足りたけどやっぱ少ない。
>> 2.VBみたいに簡単にGUI作れるの？
>> VC++未満のWin32API叩くような感じな気がするけど・・・
>> そういえば、Kylixとか聞いたけど使えるようにするのは簡単？
KDEやQtが想定してる範囲内ならMFCより楽。
それより下の層を触るときは、X11やシステムコールはWin32APIよりプリミティブなのでどのあたりまでいじりたいかによる。
>> 4.理想は言語内ですべて済めばいいけど、そうはいかないし。
>> さて、日本語のAPIドキュメントってあるのか？
>> MSDNレベルの整理されたドキュメントは欲しいなぁ。
>> 開発環境に統合されてれば最高！
>
> MSDN のように一枚岩のドキュメントはありません。
>
> 各ライブラリの API リファレンスも、新しいものは日本語に翻訳されていなかったりします。
ドキュメントの質はMSDNに及ばないですね。細かい挙動追いたいときはソースある分楽なんですが、どこまで仕様でどこまでが現在の実装なのかはわかりにくいです。
>> 7.このプログラムは将来的にも一応動くの？
>> 今作ったプログラム、とりあえず5年は動くかなぁ？
>> ランタイムのバージョンが新しくなって動かなくなって、
>> ヘルプで時間取られるの嫌だしなぁ。
>
> 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
> # 5 年後に X が無くなっていると無理ですが…。
すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。
>> 9.このショートカットキーの組み合わせ、
>> この環境だとOKだけど、別の環境でも使えるんだろうか？
>
> 微妙です。この辺りは、 95 以降の Windows の方が統一されているでしょう。
> ある程度安全に使える組み合わせはあると思うのですが、詳しいことは分かりません。
デスクトップ環境ごとに規約はありますが、カスタマイズ可能にしとくべきなんでしょうね。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
>> 難しい問題ですが、 statically linked なバイナリなら 5 年くらいは動くのではないかと。
>> # 5 年後に X が無くなっていると無理ですが…。
>すくなくともMacOSXとXみたいな感じではXは残るだろうから心配要らないと思います。
現状を知らないんですが、
Staticにしたら、洒落にならないサイズ…になったりはしないものですか？
Delphiとかでも(DelphiライブラリをStaticLinkした)実行ファイルは数百kbで、
更にWinだと本体据付なGUI足回りの多くの部分も、GNOME/KDEだと「StaticLink」
しないとならんわけですよね。
＃いくらディスクが安くなったとはいえ、やっぱり大きい実行ファイルが山のように存在してると気が滅入るのでG7
＃＃そのせい「も」あって、近年はめっきりScript言語野郎してます。小ささとメンテ性を考えるとScriptが一番かも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
でも実際はGnomeにしろKDEにしろフリーソフトの99%ぐらいはソースで配布にするかパッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
ソースからmakeすることの、初心者(??)に対する敷居を、下げないとアレですね。
…とはいえ、自分で考えてOptionいじる必要がある場合でもなけりゃ、
makeそのものが難しいっていう感覚はほぼゼロですね。
「インストーラー」がconfigure;makeをすればそれでいい、のかな…
>パッケージで配布して依存ライブラリはパッケージングシステムに任せるかで問題にはなってない気がします。
100個のアプリが、100個の「バージョン違いの」ライブラリを要求したら、
結構悲惨なことになりそうですね(^^;
ところで、やっぱりライブラリ間の依存関係ってのは、
ガベージコレクションみたいに
参照カウント法とかマーク＆スイープ法とかで
「不要」になったことを判断して自動アンインストールする(してくれる)ものなん…ですよね？？
＃メモリ管理(GC)と比較して考えると、「ライブラリを置くPathはmake時に確定すべきだ」
＃というUnix的(?)発想は、前近代的だなと思えてならないのでG7
＃名前に束縛されることで、複数の共存がやりにくくなるじゃん。
＃malloc()の出力はアドレスを問わないのが味噌なんだよね。名前空間的にも物理空間的にも"Location"の縛りが無い。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
> 現状を知らないんですが、
> Staticにしたら、洒落にならないサイズ…になったりはしないものですか？
なりますね。
Windows 環境での開発には詳しくないのですが、 Windows アプリケーションを配布する際には、 DLL の非互換性を嫌って、実行ファイルと同じディレクトリに DLL を置くのが普通になっていると聞きました。 DLL Hell と呼ばれてるとか何とか。
# 昔は、アプリケーション毎に、違うバージョンの MFC42.DLL を持ってたりしましたよね。最近は違うのかな?
こんなこ
DLL Hell (スコア:1)
インストーラーによっては、古いバージョンのMFC42.dllで
新しい物を上書きされてしまうのが問題だったと思ってます。
どちらかといえばインストーラの問題なので、
WindowsやMFC42.dll側の問題とは違う気もします。
そこらへん、Linuxだとインストールするのに、
依存関係のチェックがあるものが多いので発生しないのかも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
現状書籍は入門用はそこそこ出ているのですね。
今度大型の書店にでも行って探してみます。
KDEやQtが想定している範囲内はMFCより楽という事なので、
難易度としては、VB以上VC未満みたいな状態かな？
# VBも凝った事をしようとした瞬間複雑化するので。
ここを見ればOKみたいなAPIドキュメントとかが、
現状少ないみたいなのがこれから作るとしたら怖い点ですかね。
困ったときに見るリファレンスが難解だとか、
必要なドキュメントが見つからないといった状態になると挫折するかも。
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:1)
> Input Method 周りは鬼門です。
> 最近の gtk immodule なら、だいぶ楽になってきてはいるようですが、詳しいことは分かりません。
> フォロー希望。
>> まさかFEP毎に別のAPIをコントロールがフォーカス取得時に
>> 手動で送信とかいう冗談みたいな事はないよね？
> 日本語としてパースできませんでした。
やりたいこととしては、名前と名前のカナを入力する欄があるとしたら、
自動的に日本語入力がONになったり、カナ入力モードになったりという、
ユーザーに対しての入力支援ですね。
Win32 APIなら統一されたAPI [microsoft.com]を使用することで、
ATOKなのかMS-IMEなのか、そもそも日本語のIMEなのかを意識しないで変更できます。
>この辺は、 VB でも同じような物じゃないかな。
たしかに、VB Runtimeが無くて動かないって場合もありますね。
一応Win95時代のアプリも一応動く実績があるので・・・
LinuxのGUIアプリってどうなのかな？と思ったり。
>メニューへの登録も、いくつかの簡単なテキストファイルを用意するだけです。
これは、環境非依存・・・
例えば~/.kde～～が/tmp/startmenu/のように変更されていてもOKなのでしょうか？
こうすると、ユーザーが好きな場所に登録が出来ない気もします。
まぁ、ここらへんはLinuxで動く対話型GUIなインストーラーが、
KDEやらGnomeが標準で用意してくれたら良いのかもしれませんが。
＜おふとぴ＞
# 傍から見てると、LinuxのGUIアプリってシェアを
# 身内で食い合ってる様に見えるのは気のせいなんだろうか？
＜/おふとぴ＞
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
glade休眠中…お願い復活して。
> 最近は wchar_t があるので、日本語を扱う程度なら、意図的に変なことをしない限りは大丈夫です。
cygwinでは16bitなのが泣ける (;_;)
Re:とあるVB房がLinux開発環境に抱いているイメージ (スコア:0)
最近はけっこう増えてきた・・・と思う。
Re:日本の開発者が増えるには (スコア:1)
今まで見聞きしている限りでは、なんかフツーvs開発者の比率って1000:1程度の様な気が・・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:日本の開発者が増えるには (スコア:1)
そうなんでしょうか？この記事 [itmedia.co.jp]によれば、 となってるんですけどねぇ。Re:日本の開発者が増えるには (スコア:2, すばらしい洞察)
さらに、公開するとなれば、他人が使うことを考えなければならないわけです。いろいろな人/場面を想定する必要があって、かなり気力がいると思います。
# 最近仕事?で作っているプログラムは、テキストフィルタ的なものばかり。
# モデル化データを作って、シミュレータに突っ込んで、出力切り出してグラフに加工...
# 拡張に拡張を重ねたせいで、人には見せられないプログラムに。
なんちゃってプログラマ?
Re:日本の開発者が増えるには (スコア:1)
アプリもいいんだけど、(GUIな)ライブラリ…典型的なのはWidget…も
みんな沢山作って欲しいなあ。
と、Delphi出身者な俺は思うのでした。
フリーかつソース公開(The OSI OpenSouceかどうかはさておき)な
Widget(Delphi弁だとComponent)が結構沢山あるんですよね。あれが気持ちよかった。
で、APIというかフレームワークというか…が秀逸ならば、
GNOMEの一番偉い人によれば、
「2000行で気楽にWidget作って公開！なんてのがさくさく出来るっしょ」
ってことだそうです。
プチアプリとしてのWidgetってのは、結構いいもんですよ。いろんな意味で。
で、その次の段階として、
そういったフリーのWidgetをかき集めてアプリらしきものを
とりあえず手早くでっち上げられる環境が有れば、
めでたしめでたし(=「アプリ」の生産性がshなみになる)です。
ん。たぶん、Widget作者とアプリ作者が、
(あくまで結果としてだけど)分離されるといいんだよね。
…ご健闘をお祈りします。
GUI作るのマンドラケ(AA略) (スコア:0)
Re:GUI作るのマンドラケ(AA略) (スコア:0)
似たものとなるとどうしても前のと比べちゃうし。
GTK+1.xについてたファイルマネージャーっぽいやつはよかったんだよな。
TAB補完に慣れた指で違和感なく使えるよう作ってあって。
ああいうCUI文化をうまく継承したGUIなんかがもっと増えたら
おもしろいんだけど。＞PC-UNIXのGUI
Re:日本の開発者が増えるには (スコア:0)