  |
はてなキーワード: ソースコードとは
どうしてあんな馬鹿なの？
アセンブリとかソースとかコードとか、どうして中途半端にカタカナ英語なんかにして、和名を付けてあげなかったの？
ノムリッシュじゃないけど、ファルシのルシがコクーンをパージみたいに字面見てるだけで拒絶反応バリバリ出るんだけど？
たまーに構造体とかちょっと分かりやすい和名つけてるけど、基本カタカナの羅列で頭痛くなってくる。お前はルー大柴か。
フールプルールとかフェールセーフとかフォールトトレラントとか、こんなもんカタカナ表記にするよりまだ英語表記にした方が覚えやすいだろ。
そもそもソースコード全部英語なんだからさ。解説でわざわざカタカナ表記にする必要ないじゃん。ややこしいんだよ。
なんか、変に話が大きくなってますが、元SIerとしては単なるあるある系のクソ仕事話の一つって感じの、Excelスクショエビデンスについて話をしておこうと思います。
最初に結論を言っておくと、
「意味があるのは分かっているが、そもそも責任回避のための資料作りなんて出来るだけやりたくないし、そんなのが大量に必要であること自体が気に入らねえ！」
ってことです。
参考:
Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） | 羽根帽子の太公望
まあ、意味があるのは分かる。やってた事もある。
とは言え、何の意味かというと発注元の企業とゴタゴタが起こった時の責任回避の資料作りという意味で。
後になって問題が起きた時に原因究明の資料になるとかいう話もありましたが、それはかなり怪しい。
適切な粒度で切られたテストケースと更新がある度に正確にメンテされ続けるドキュメント管理力が必要ですが、そんな信用度の高い文書あんまり見たことない。
結局、動いてるシステムとソースコード見るしかない。その時の参考資料になるドキュメントは必要だと思いますが、それがExcelスクリーンショットかというと……。
どうしても再現環境を用意できず、机上で推論するしかない場合は役に立つかもしれませんが、そもそもそんな重要なシステムで何でそんなところケチってるのか意味が分かりません。
後、ソースコード読めない上流のSEがバグ原因を推定してお客様に説明する、という不毛な作業をする時にも役に立ちますね。
やはり、責任回避のための言い訳資料を作る、という名目が強いように思えます。
大半の人にとって、そもそもこういう資料作成自体が不毛でやりたくないと思います。
テスト工程とか余計なこと言わずに、訴えられて損害賠償請求されたくねーからやってんだ！と新人に説明すべきだと思う。
(こういう事ネットには色々書いてあるんだけど、会社は教えてくれないんよね、何故か)
大体、なんでこんな事やってるかっていうと発注元の受け入れ作業をベンダーが肩代わりしてるからです。
自分が注文したものがちゃんと動いてるのかの確認までベンダーに投げるので、「やった」「やらない」を過剰に説明する資料が必要になる。
専門知識を持った人材を抱えておくことをコストだと考えてるから、もっと無駄な事が世の中に発生してしまう。
そして、これのせいで付随して更なる問題が発生する。
顧客提出する資料に専門用語を含めた説明文を書くと、言葉が理解できない、という理由でリテイクをくらう場合があります。
説明資料じゃなくて、開発者や運用担当者が参照するための技術資料なのに、技術的に正しい、とかはどうでも良くて顧客が理解できる言葉で書け、ってことですね。
向こうのレベル感を探り探りしつつ文言を選んで説明分を付与する不毛な仕事が求められるのです。
これが顧客に対する誠意だと言うんですからお笑い種なんですが、まあ向こうがそれに金払う、って言ってんだから作るんでしょう。
既に十分不毛なんですが、これに輪をかけるのが体裁というやつです。
スクリーンショットの位置や文頭が微妙にズレてたりすると怒られるやつです。
それが、そんなに重要なのかどうかについては、最後まで分かりませんでした。
項目幅を調整して印刷可能なページに適切に収めるのに消費される時間が辛い。
後、カーソルをA1に戻しとけ、とかも全く意味が分からないし、納品前に数時間かけて印刷して判子を押して回るのも意味が分からない。
こんな単純作業を人間が手動でやっててミスらん訳が無いだろうに。
気を付ける、とか真剣にやる、とかで解消できると思ってるなら、お花畑過ぎるだろと言わざるを得ない。
しかも、自動化するために諸々やってると、最悪サボってると見做されるし、ひどい場合は、作業用PCに使えるソフトが限定されてて、スクショ取るツールさえ入れられない事があるらしい。
そこまで行かなくても、社内プロキシの穴を付いて開発環境を落としてきたりして、最悪セキュリティ担当の人に怒られる場合がありますね。
なんでこんな面倒なことしなきゃならんのだとソウルジェムがガンガン濁っていきます。
(メモ帳でもありゃいいだろ、という話もあるかもしれませんが、俺のような凡人はそれはそれでソウルジェムが濁ります)
まあ、それを回避して何とか自動化して省力化できるようになったら、他の人の作業時間と同じぐらいの見積り出して、本当にサボるんですけどね。
ダラダラと色々書きましたが、まとめるとこういう事です。
企業活動として意味があるのは分かるが、その根本的な目的は誰かが手抜きしたコストを肩代わりしてるだけに思える。
ただ資料を作るだけじゃなくてすげー細かい注意が必要になるのだが、そこに合理的な意味があるのか分からない。
作業自体がめっちゃ面倒くさいのだがその面倒くささを解消する方法に何故か制限がかけられている。
そして、世の中のプログラマーがどうであるかは知らんけど、俺はそんな作業が大嫌いだ。
むしろ、Excelにスクリーンショットを取って張るなんてのはどうにでもなるんだけど、それに付随している業務慣習の大半が意味分からなくてクソ喰らえである。
というわけで、意味があるとかそういう主張はどうでも良くて、そんな仕事やりたくない。
まあ、それしか金を得る方法が無いんだったら、嫌々でもやりますが……。
しかし、そもそもの話、実際冒頭で挙げた参考エントリの人も心病んでるし、他にも病院送りにされてる例が多数あるわけで、
仮にこれが本当に必要だと認めるにしても、人間の心をすり潰してまでやらなきゃならないような工程が、
当然のものだと受け入れられてる業界は最悪じゃねえのかと思う。
従業員の精神を壊してまでやらなきゃいけないような事なのか、これは。
必要とか必要でないとか以前に、こういう事やると人間の心が病むんだよ。そんなものが仕事なんだったら、そりゃ人間働かなくなるだろうよ。
そんなすぐに世の中変えようもないしどうしても作らなきゃいけないんだ、という場合は、せめて自動化に対する障壁を外して欲しい。
見た目の凝り具合とかは本当に必要な最小限度の体裁にして欲しい。
http://anond.hatelabo.jp/20140722142248
「システムを使った社員がソースコードを持って帰って公開したらどうなるの？機密情報の流出だよ。」これはグレーです。
なんとも言えません。
webシステムでも絶対にソースコードが流出したらダメな場合はライセンスを買った方が良いです。
http://anond.hatelabo.jp/20140722001658
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
これは大丈夫です。
GPLではソフトウェアの配布時に関係してくるので関係ないです。
これはグレーです。
なんとも言えません。
というのが脅し文句。
ようするに「裁判でどういう判決が出るのか（俺は）分からないので、怖かったら買え」ということ。
でもよく考えるとMySQLが出て長い年月が経ってるのにそういう事例が無い（少なくとも俺は知らない）って時点でリスクなんて無いと思う。
でもいまだにwebシステムでも前者の勘違いをして買ってくれる人が意外に多い。
http://anond.hatelabo.jp/20140722034243
これはMySQLクライアントを利用してDBに接続する多くのwebシステムではグレー。
MySQLに同梱されているクライアントソフトを使わずに自前でクライアントを作って接続してる場合は確実にGPL汚染しない。
前述の通りグレー。わからない。
一端GPL汚染したバージョンが出回った後でライセンスを変更するのは不可能だけど、
次のバージョンからGPL汚染しないように作り直して、ライセンスを変更すれば、
http://anond.hatelabo.jp/20140722143245
個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
それであってる。
かつてのGhostscriptが、当初GPLで開発→途中から商業利用制限のライセンス、ってパターン(但し、GPL版もメンテされ、先端のバージョンの機能が遅れて実装されていた。今は独自ライセンス版はなくなってGPLオンリーなのかな?)
有益な話だし、GPL関係でググってこのページを見た人のために勝手に補足と個人的な疑問を放流してみる。
適当に調べてた知識を記憶をたよりに書いているので、間違いがあれば容赦なく指摘して欲しい。
# どうでもいいけど、元増田の話でOSがLinuxだったりしたら笑うw
GPLは元増田で書かれている通りで、WEBシステムを閲覧しただけではソースコードを請求することはできない。RMSらもこれには気づいていて、この穴を塞ぐためにAGPLというライセンスができた。このライセンスのソフトウェアを利用した場合、WEBシステムであろうと利用できる人はソースコードの請求を行えるようになる。
これは別にWEBシステムに限らず、ユーザーが何らかの形で利用できるシステムなら、ソースコードの請求が行える。
申し訳ないが詳しい所は知識不足でよくわからない。だけど、下記の記事の通り現在の開発元のOracleの見解である。すなわち、MyODBC(GPLのMySQL用ODBCドライバ)を使わず、GPLでないドライバを用いて接続してしまえば、開発したソフトウェアがGPLにならない。
http://plaza.rakuten.co.jp/matsunopage/diary/201011300000/
# 個人的にGPLがRMSの著作権Hackなら、OracleのコレはGPL Crackだと思っている。「GPL汚染が嫌なら有償ライセンスで契約しろ」と言われた話を聞いた事があるからだ。
おそらく持ち帰れないのではないかと思う。なぜそう思うかというと、普通、プログラマが書いたコードの著作権は会社に取られるし、GPLでライセンスされたソフトウェアを受け取ったのは会社であってプログラマ個人ではない。GPLでライセンスされたソフトウェアを物理的にもっていく事は可能でも、きちんとライセンスを受けた訳ではないので機密情報の漏洩にしかならないと思う。
単純な興味なのだけど、例えば最初はGPLだったが途中からはプロプライエタリ(ないし、GPL非互換なライセンス)に変更可能なのか知りたい。個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
http://nippondanji.blogspot.jp/2010/06/gpl.html
http://d.hatena.ne.jp/karasuyamatengu/20110126/1296004598
なんで、グレーなのか。なんで、無理なのか。どのような考えでグレー、無理という結論を出しているのかきちんと書いてもらえますか？ 私の考えが間違っているならなぜ間違っているか指摘していただけますか？ あるいは、下記の増田さんのように具体事例を出してもらえますか？ プロプライエタリに戻せないというのなら下記の具体事例はどのようにお考えですか？
http://anond.hatelabo.jp/20140722071548
とした場合に、PHPを飛び越えて(間接的にしか接続していないにも関わらず)開発したシステムにGPLが適用されるということですか？ その場合、PHPにもGPL汚染が発生するということになると思いますが、間違いありませんか？(FOSS除外規定を設けているのはMySQLであって、FOSS除外規定と無関係な開発したシステムがGPLになってしまうと、開発したシステム側からGPL汚染が発生するという考えから。)
元のパラグラフは下記の通りです。
あと、MySQLのデータベースサーバに接続しただけではGPL汚染は発生しません(AGPLはそのためのものなのは前述の通り)。また、PHPは接続するクライアントになりますよね。ということは、MySQLと一緒に開発システムを一つのパッケージとして納品しない限りはGPL汚染は発生しないのではないでしょうか？(WEBシステムでそんなこと普通しませんよね。yumとかでインストールするし)
根本的な問題として、FOSS除外規定はGPLソフトウェアと他のFLOSSをリンクする際の問題を解決する物であって、MySQLのデータベースサーバに接続する場合には関係のない話だと思います。おそらく、問題だとお考えなのは、PHPのドライバがOracle製のGPLプログラムをリンクしていたためPHPのドライバを利用すればそのような問題が発生するという事だと思います(さらに追記。この通り書かれていますね。よく読んでおらず、失礼いたしました)。現状、PHPライセンスとなっているMySQL Native Driverを利用すればそのような問題は発生しないはずです。
http://php.net/manual/ja/mysqlnd.overview.php
かりに、おっしゃる通り、開発システムもFOSS除外規定に含まれるFLOSSにしなければGPLになってしまうとした場合、それはMySQL独自の問題であり、他のFLOSSに一律で当てはまる問題ではないということでよいでしょうか？ なぜこのような質問をするかというとMongoDBが同じような問題を抱えているからです。下記のURLの通り、MongoDBのコアサーバはAGPLですが、ドライバにApache licenseを適用し、開発システムにAGPL感染が発生しないようにしています。
http://www.mongodb.jp/mongo/licence
上記の様なケースにも実用的に対応する為、（AGPLを採用しつつも）我々はあなた方の（MongoDBを利用する）クライアントアプリケーションは（MongoDBとは）別物扱いする事を約束します。これを円滑に行う為、mongodb.orgサポートのドライバー（あなたのアプリケーションとリンクする部分）はApache licnese（コピーレフト）の元公開します。
返信お待ちしております。
冒頭に書いた通り、間違いがあれば容赦なく指摘してください。
MySQLに限らないけど、「GPLは営利目的では使えない的な思い込み」は止めて欲しい。
先週、システム開発の提案で客先に行ってきた。
当方、30前半のSE。対応してくれた担当者は40代後半の情報システム部門の方。
提案したシステムの規模はそれほど大きくはなく、お客さんからもあまり予算はないと言われていたため、RDBMSに「MySQL」を使ったWebシステムを提案したところ、「それほど可用性は求めてないし、無料で使えるDBの方がいい」と言われた。
あぁ、商用ライセンスを購入すると勘違いしたんだな、と思ったので、「MySQLはGPLライセンスもあるので無料で使うことができますよ」と説明したところ、担当者の顔が険しくなった。
「GPLだとソースコードを公開しないといけないんだよ？たとえMySQLのソースコードを改変していなくても、MySQLを使ったソフトウェアであればソースコードを公開しないといけないし、それを企業で使おうとすると犯罪になるよ。」
「だからウチでは重要なシステムはOracleを使っているし、重要度が低いシステムPostgreSQLを使ってる。」
「たまたま提案先がウチだからいいものの、他の企業にそんな提案すると恥をかくし、あなたの会社の信用も堕ちる。」
いろいろ言われたけど、要約するとこんな感じ。
「確かにGPLだと他の誰かにMySQLを使ったソフトウェアを頒布する場合はソースコードも渡さないといけないですが、今回は御社に導入するWebシステムですから問題ないですよ」
とは返したものの、
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
「システムを使った社員がソースコードを持って帰って公開したらどうなるの？機密情報の流出だよ。」
と捲し立てられてしまった。
心の中では「Webシステムだと利用者全員にソースコード公開とか、なわけねーだろ」と思いつつも、相手の勢いがスゴいし反論するための明確な情報を持っていなかったので一旦持ち帰って再検討することになりました。
http://www.ipa.go.jp/files/000028332.html
英語が苦手なのでIPAが公開しているGPLv3の日本語訳で確認したところ、「0. 定義」の項目に以下の文言があった。
著作物の「コンベイ」（convey)とは，プロパゲートに当たる行為のうち第三者が複製すること又は複製物を受領することを可能にする行為をいう。ただし，コンピュータネットワーク上での単なるやりとりであって複製物の伝送を伴わない場合は，コンベイに当たらない。
そりゃそうだよね。てかWebシステム利用者にソースコードを公開しないといけないとか誰が言い出したんだよ。
で、結局提案はPostgreSQLに変更しました。ライセンス云々関係なくPostgreSQLに統一されているんだったら運用コスト面でその方がいいし、MySQLを提案したのは俺がPostgreSQLより得意だからってだけだから。
ライセンスについては調べたことを担当者に伝えるかどうか思案中…。
ここまで捲し立てられたのは初めてだったけど、今までもお客さんから「GPLだけど商用ダメなんじゃないの？」って言われたことが多いんだよね。
もう一度言うが
ベクター: http://www.vector.co.jp/
言わずと知れた老舗ソフトウェアダウンロードサイト。毎日更新されるコンテンツは「新着ソフトレビュー」くらいなのに毎月7800万PVの高○○を誇る。（巷で人気のはてなは全サービスで2億PV/月らしい！ワーオ！）ベクターの広告掲載料はPVあたり0.05円だとか。今は…、…といった企業の広告が掲載されている。
世間に高い印度象を与えた遠隔操作ウイルスバスター事件に対するHIT-BITの印象はどうだったろうか。スーパーハッカーが自己満足のために起こした事件とか？
スーパーハカーといえばやはり遠隔操作。遠隔操作でCDトレイがガコンガコンだろうか。そう考えるとEjectコマンドユーザー会なんか完全にブラックハット集団だろ……何人いるのか知らないけど
この騒動の中で耳慣れないソフトウェアが複数登場した。例えばこういうものだ。
我々が普段ホッテントリで目にするアプリとは何か違う。例えばサーバ→鯖→ﾏｶﾚﾙのような発想と同じ匂いを感じずにはいられない。それに「パケット警察」よりも"SoftEther社のパケット監視ツール"と言われたほうがピンと来る。
ベクターにはこういったゆるキャラ的名称を持つアプリケーションが数多く登録されているのである。
私は空気読みができる人間だ。つまり何が言いたいかを改めて申し上げると、エバーノート活用法と聞けば、自分の時間を犠牲にしてでもライフハックMethod収集に勤しむ意識高い系ライフハッカーや、Markdown対応と言われればナンでもカンでも有り難がる技術系アーリーアダプターの方々や、はてブなどのソーシャルメディアに居を構える人たちと、ベクターユーザはどこか違うということを思わせる印象操作である。
増田一族の皆さんは日本で一番使われているWebブラウザをご存知だろうか？ ……その通り、IE9である。ところがだ・私は１０年以上、隔週一度の頻度ではてなブックマークを利用してきたが、いまだにIE9のハック記事がホッテントリ入りしたのを知らない。ちなみにOperaもない。
ベクターで人気のアプリケーションで「めもりーくりーなー」をご存知だろうか。不要になったメモリ領域を回収するシステムメンテナンス系ツールなのだが、実態は大量にメモリ確保をするものだ。Windowsはメモリが不足すると使用頻度の低いメモリ領域をシステムディスク上のスワップ領域（仮想メモリ）に追いやり、物理メモリを確保する。それが空きメモリ復活のからくりである。
遠い昔、メモリ最適化ツールとして「ただ数を足したり引いたりするだけのプログラム」が持て囃されたことがあったが、めもりーくりーなーのコア部分はメモリ確保のAPIコールをするだけで済んでしまうので、足したり引いたりほども難しくはないのである。
そんなツールが人気のベクタソフトウェアライブラリというと誤謬（ごびゅう）があるかもだが、そんなベクターが月あたり7800万PVである。ワオ。「そんな」とか言えない。そんなベクターからは毎日収録ソフトのアップデート通知が来るが、再インストールとほぼ同じ手間をそうそう小まめに行う人間がいかほどいるだろうか。注目ソフトウェアを取り上げる「ベクターソフトウェアニュース」ははてブと違って1日1回の更新だし、メールマガジン「ベックル」だって手作業での編集だ。それでもはてな2億PVに対してベクター7800万PVなのである。それを620万のUUが支えているので、1人あたり12PV余り稼いでいる計算になる。今のはてなは2億PVに対し4000万UU(U'ｪ'U)→1人あたり5PV。情報の更新量で言えば個人ブログのスターダム層とあまり変わらないのではないだろうか。MLBに例えるならブログ界の野茂英雄とも言える旧イケハヤ書店さんが今年3月に100万PV/50万UU達成を記念して焚き付けを行なっていたが、同程度の情報更新量とするとイケハヤ100万パワーとベクター7800万パワーの差は一体何なのか。火事場のクソ力vs平時のキン肉マン並みの差である。（ちなみに超人界の神々が1億パワーであることもご考慮いただきたい）これは何か常連にしか見えない㊙コンテンツがあるとしか思えない数値である。
（そういえばはてなダイアリーからニコニコのブロマガにもらわれて行ったベックルハリー先生は、映像でもお見かけする機会が増えて、以前より増してご活躍のようですね。ニコニコ静画のコンテストで新作の絵師さんを決めたそうで気になります）
注: 「めもりーくりーなー」はCodeZine「マンガで分かるプログラミング用語辞典」やマンガでわかるJavaScript / Javaプログラミング、最近ではnoteでも連載中のクロノス・クラウン 柳井 政和さんの著作です。実際にはメモリー最適化のためのニーズに合わせたUIを備えているため、前述した原理だけのアプリケーションではありません。
ベクターはおかげさまで25周年！今年が平成26年、つまり平成も25周年を過ぎたところ。ベクターは日本の年号が「平成」に変わったのと同時期に創業した会社なのであります。平成の始まりは1988年2月。その頃あなたは何をしていましたか？ まだ生まれていませんか？それとも友達が続々とファミコンを手に入れていく中、1人だけMSXを買ってもらってデータレコーダーで5分かけてロードした後、ただひたすらゴジラと戦う3DダンジョンRPGや、アスキーや徳間書店の雑誌に載っているプログラムリストを打ち込んで、F5を押しては"Syntax error"を出すという流れ作業の話をして「ふーん」と言われるだけの交友関係に何かコレジャナイ感を感じていた頃でしょうか？もしかしたらアイドルから一転してラ・ムーを結成した菊池桃子さんとHelloみかんに衝撃を受け、自称親衛隊を辞めようかどうしようか、辞めるとしたら世間的に許されるのかどうかと迷っていた頃……という方もいらっしゃるのではないでしょうか？ そのころベクターはもう走り出していたんですね！！！！！！！！！！！！！<3
199x年から始まったソフトウェア・ライブラリサイト「Vector」の累計ダウンロード数は、1999年に1億DLを達成した後、毎年1億（ときたま2億）ずつ堅調に増加して今年19億DL達成。
本業がオンラインゲーム事業になってしまったベクターだが（「創星紀アステルゲート」大好評サービス中）、ソフトウェアライブラリは依然として健在だ。7800万PVを支える620万UUに7800万のベクター体験を提供している。（わーお）
ベクター体験と言えば、最近では「XPフォーエバー」が人気だった。XPが意味するユーザー・エクスペリエンス(UX)が後発OS(というかiOS)に受け継がれた現在においても、WindowsXPは走り続けているらしい。そして走り続けなければならない。定年退職と同じだ。ゴールが年々遠のいていくんだ。プログラマー定年説だって昔は30歳だった。それがいつの間にか35歳定年説になっている。40歳になる日もそう遠くはないだろう。30歳が若くない？そんな言い分が通用するのはアイドルとスポーツ選手とプログラマーくらいのものではないのか。政治家なら40歳で若手。そもそも一日中イスに座りっぱなしで政治家ほども動かず、身のこなしと言えば手を動かすくらい、チェリーの黒軸キーより重いものは打つことがない仕事がなぜ「体力勝負」と言われるのか。「プログラマーやってたんで体力には自身があります！(*°∀°)=3」とか引越し業の面接で言えんの？1日じゅう立ち仕事で刃物を扱ってる床屋の主人を差し置いて体力自慢できんの？
私は空気読みができる人間だ。落ちのない小話がそう何度も通用するとは思わない。本題に戻ろう。
さて、増田一族の皆さんはベクターのご当地ゆるキャラをご存知だろうか。その名も「べく太」である。心優しき少年ではあるが学校での成績がずば抜けて悪く、テストでは全問不正解の上、自分の名前を「べく犬」と書いてマイナス点をもらう奇才ぶり。友達はそこそこいるが、成績の悪さや自身のずっこけエピソードにより、知らない人にも名前を知られている有名人気質。得意科目は射撃とあやとり。手に座布団を持ったスタンディングポジションから就寝までの速さを競う競技昼寝の速さにおいて世界クラスの実力を持つ。いつも((ﾐﾟoﾟﾐ))の影にいるため主人公とは思われない彼だが、劇場版長編「のび太の結婚前夜」ではアレをナニされても決してああはしないという彼の秘められた人間性が描かれている。
そんなのび太が最も輝いていたのがシステムメンテナンス系ツールの紹介記事であった。
他とは比べ物にならないほど豊富にあるハードウェアの性能を引き出すため、Windowsの世界ではさまざまなチューンナップ技術が磨かれてきた。メモリ最適化、レジストリクリーニング、ディスクキャッシュの最大化、RAMディスクの利活用、ビジュアルテーマ/アニメーションの無効化、IEの常駐、スタートアッププログラムの削減、サービス系プログラムの無効化、ＥＸＥの圧縮、RARの活用、標準ツールよりも高度なサードパーティ製ディスクデフラグ＆メモリデフラグ……、やることはいっぱいだ！でもこんなに手間をかけられるWindowsはかわいいなあ！そうやってPCチューンの腕を日々/.J で研鑚しあうマイルドハッカー達は磨き抜いたファイルコピーのスピードに一喜一憂したものである。
特にベクターには日本人により日本語で説明された扱いやすいメンテ系ツールが数多く登録されていた。使い方を誤れば手塩にかけて育ててきたWindowsに打撃を与えかねない分野であるため、「日本人にとっての分かりやすさ」は重要視される要素だ。そんな分かりやすいツールをさらに親しみやすく紹介する子供だましが紹介記事におけるべく太の役目である。
今ではべく太も良く読まれた記事のランキングでしかお目にかかれなくなってしまった。今や世間は萌え擬人化を通り越してゆるキャラブームである。いやブームさえ通り越して文化である。べく太はゆるいというよりマイルドなためかこのブームに乗っかろうという動きはまだ見せていない。これは残念なことである。（はてなもゆるキャラ路線をやめてしまうのだろうか）
ところどころかいつまんで述べたため、いくぶん主題がぶれた印象はあるが、
そんなベクターのユーザにリーチすることを考えないで、一足飛びに海外にロンする発想はちょっとチョンボしすぎなんじゃないの。その前にIEのセキュリティ問題で右往左往する人たちを相手にするのが先でしょ。そのあとは日本人口のメイン層である前期高齢者な。
情報社会を牽引する立場のソフトウェア開発者とは言っても、テストコード書いてこまめにリファクタリングしていくらでもデプロイしては動作確認できる人たちばかりじゃないの。一次請けから渡された画面設計書をメンバーに一人一枚ずつ手渡してアサイン完了、がんすけで開発スケジュールを引きつつ「これでどうだ？」とメンバー一人一人と納期交渉をするＳＥもいるの。ソースコードとほぼ同じ内容なので、スケジュールには含まれ得ない詳細設計書を「まぁ気持ちは分からんでもないが本来はそういうもの」という理由で実装前提出させたりするの。すべてが決まって検討課題がメンバーのメンタル面だけになった時点でキックオフ・ミーティングを始めるのが開発フローになっていたりするの。
これに対して事あるごとに穏やかな語り口で「私は雑用ですから」とつぶやくＳＥもいて、彼の場合は画面設計書をメンバーひとりひとりに渡して顔を伏せつつ実に申し訳なさそうな口調で「これぐらいでお願いできませんか」と納期交渉をしつつがんすけ２でスケジュールを引く人でした。
そんながんすけをダウンロードできるのもベクターソフトウェアライブラリなのである。がんすけ / がんすけ2 / （窓の杜にもあるよ） / （公式です）
話がそれたので本題に戻そう。
タイプは違うが、両者とも大差なくマッチョメンであった。ＳＥなのに。ここから少し余談を挟むが、その後面接をしたとある派遣会社の派遣プロマネもマッチョマンであったが、マッチョメンに出会ったのはそれくらいなので特に私の人生がマッチョメンで占められているという話でなはい。
私も筋トレすれば強くてたくましいＳＥになれるのかな、、、
いやスケジュールが押したからって突然開催されるようになった朝会に、シドニアの騎士のOPを歌いながら入ってくるようなＳＥは私の目指すところではないな。戦いの場への入場曲はもういいので設計をして下さい、設計を。適切な設計で工数を減らすのは、あなた方の役目でしょ。あなたの敵はここにはいません。何も打ち砕かなくていいのです。そんなことよりぴょんぴょんしましょう。ぴょんぴょんのほうがメンタル的に優しくていいです。ぴょんぴょんですよぴょんぴょん。
このままで、果たして定年までぴょんぴょん続けられるのかな……。定年……って何歳だっけ……。
元々は55歳か。それが20年で60歳になって……さらに20年経って65歳が当たり前になったのね。じゃあ、あと20年したら70歳が定年かぁ……今働き盛りの人たちは70歳から年金受給者だね☆ 平均寿命が延びたぶん定年がずれていくということは「人は働くために生まれる」というのがこの国の常識なんだろうね。（だって政治家は自分を選んでくれた選挙区の空気を読んで法律に反映させる役職でしょ？） そんでもって現在の定年が65歳、日本人の平均寿命は80代前半。最高齢が110代なので医療福祉諸々の発展で平均寿命と定年があと30年延びる可能性も？95歳で定年！？いやいやいや……そのころには日本人の人生観も変わってるだろうから……いやいやいや……変わってるかなあ。
だったらプログラマーは何歳定年説になっているんだろう。IE9をシェアNo.1に押し上げるような職場に勤めていれば何も心配ないのかな……また大きなパラダイムシフト──という言葉がもうずいぶん久しぶりだけど──が起きてプログラマー定年が上がるのかな……パラダイムシフトじゃ上がらないかな……ライブラリとツールのほうが大事かな……（大体、オブジェクト指向だって末端のアプリケーションエンジニアにとっては「例にならえばいいだけのもの」だったし）……何かを速く便利に自動化するツールよりも、テストコードを書けばそれに合うライブラリを探してきてくれるエージェント指向システムが実現されないかな。今のところ再利用可能なコードを探す手段はドキュメントを検索するのと、ソーシャルふにゃふにゃで誰かに教わることくらいしか無いし。そんなパラダイムシフトが早いとこ起きないかなー起きればいいなー「お前が起こすんだよ」とか言う奴ぜったいいるだろうけどおれはおこせないしなー。
結局、定年って定まってないんだよね。不定年だよ。定年は不定年。同じ境遇の人間が多数いればその都度社会が対策とってくれるだろうし、先のことを気にしても仕方が無いよね。──ってことでハラオチ。
そんな私のベクター体験を元に、ベクターユーザからも訴求されそうなはてなブックマークUIを考案するのが本稿の主題である。
(Dan the full stuck engineer.)
Shared by iNotes - Sync Note with iOS
まずは、いま自分の置かれている状況から、どの言語を選ぶべきかを考える。
複数の要素があるなら、優先順位をつけること。
参考として、僕の考える優先順位は以下のようになる。
まずは目の前のことをきちんと片付けられるひとになろう。
焦燥感などあるかもしれないが、雑誌やブログは必要以上に煽る傾向がある。なぜならそれで稼ぐひともいるからだ。
他人が進める技術はポジショントークだと思って問題ない。自分とは立場が違うからと、参考程度に読むべき。
流行は過ぎ去るのが早い。習得したが流行が次に移る可能性もあるので、博打すぎる。
仕事で使われている言語は、採用された経緯が絶対にあるので聞いてみるべき。
「ハードやOSの都合」「パッケージソフト」「社内に有識者が居る」「お客様の指定」のように、だいたいは大人の事情であることが多く、選定される言語は会社や現場によって違う。
また、仕事でソースコードを書く場合は、作成後「保守」「運用」と言った、作ったものに手を加えることが必ずと言っていいほど発生する。保守運用は実装者以外が担当することも多い。それらを想定した引き継ぎや改修のコストも考慮され、言語の選定が行われている。
そのため、仕事で使用する言語はだいたい似たような作りになっている。あまりかけ離れたものだと技術者の確保が難しく、教育のコストも馬鹿にならないからだ。
つまり、ひとつの仕事で使用する言語を「高いレベルで」習得すると、他の言語になっても多少の違和感レベルで移行ができるようになる。繰り返すが、まずは目の前の仕事で使われている言語を修得することだ。
そして次のステップで、余裕ができたときに自分が実現したいものを制作しよう。
まず、実現したいものの要件定義をしよう。どんな環境で動くものなのか。ブラウザ必須？アプリがよい？どんなライブラリを使ったら楽になるのか。データベースは必要なのか。グラフィックは凝る必要があるか。
と、考えていくと、自ずと言語は見えてくるはず。
はじめての場合は、使用ユーザが一番多いものを選ぶとよい。ユーザが多いということは、情報がたくさんあるということ。ググったら出てくるのは素晴らしい。
そして、使用者が多いとバグも少なくなっているということだ。知らない分野であると、自分のミスなのかバグなのかの判断がとても難しい。
着手する前に、作りたいものの技術をどう実現できるかを前もって調べて、詰まって投げ出さないように予防線を張ろう。
部分の理屈は解っていても手を動かさないと見えてこないものがある。
意外に準備が必要だったり、素材作りやデータ入力での反復作業、部品を結合したときに気づく設計の重要性、リファクタリング、テストの観点だったりと。
最初から最後まで見通すことができると、他人から作業を振られた時に、どの部分をやっているかが見えてくるようになる。振られた内容に不備不足を見つけてプロジェクトに進言できる人は、プロジェクトで重宝されて居心地がよくなるのでオススメ。
ということで、まずは規模が小さいものを作るとよいと思う。大きいものにチャレンジしても、社会人になると時間も少ないので途中でやめてしまう危険もある。例えば、仕事中で感じる何か1手順を楽にするようなものとか、ある個人の作業が楽になるようなものなどが、要件が把握できる規模なので、ちょうどよいと思う。先ほど考えた「自分が実現したいもの」は、その後でもよいと思う。僕の経験から、大きいものを作っていると知識が溜まっていくに従って最初から作り直したい病が発生するからだ。
簡単に要点をまとめます。
以上。着手前の心構え的な部分を書いてみました。
知ってると思うけど、ほんの2〜3分の動画を10〜20本程度見るだけで、簡単にプログラミング入門できるサイト。
そのコンセプトはいいと思うんだけど。
「えー」うるさすぎ。
これ気になりだすと内容に全く集中できない。
んで、作者もこの問題は知ってるらしい。サービス開始時からだ。→ http://www.ideaxidea.com/archives/2011/11/dotinstall_launched.html
こんな致命的ですぐ直せるような問題をなぜ改善しようとしない？考える時間がほしいならゆっくり喋ればいいじゃん。
「癖だから」で済む問題じゃない。知らない分野の解説も多いからメシ喰う時間に見ようと思ったけど、これのせいで一つも見る気しない。
さっきの「えー」問題も含めて、クオリティは作者が暇つぶしに適当に解説してみました、みたいな感じ。
まぁ無料だからこれでいいのか、とも思ってたけど、久しぶりに見てみたら有料サービス始まってた。
文字起こしを見る権利とか、動画内のソースコードをコピペできる権利をもらえるらしいんだ。
ソースをなぜ掲載しない？ってのは前から疑問に思ってた。有料にしたかったんだね。
あんな短いソースくらい普通に掲載してくれよケチ、と思う。本末転倒っていうか。
文字起こしはけっこうコストかかるから有料であるべきだが、こんな暇つぶしクオリティの内容の文字起こしを読むぐらいなら最初からちゃんとした文章の解説なり本なり読んだほうがいいじゃん。
「動画で解説していること」がこのサイトの唯一のアイデンティティなんだから文字起こしに頼るべきでないし、その動画にすべて「えー」が入ってるのはやっぱりサイト全体の価値を大幅に低くしてると思う。
んでさ、ここがいちばん書きたかったとこなんだが、文字起こしってのは全ての「えー」が漏れなく入ってんのかな？想像すると笑けるわ。
協調性がなくモテない自分が、仕事や恋愛における多くの失敗を重ねて得た教訓を並べました。
iPhoneのメモに残して、毎日振り返っていこうと思います。誰かのためにもなれば幸いです。
普通の技術レベルで言ってもソースコードのライン数で言っても何倍どころか十倍ぐらいコード書いて
ひたすら残業してようやく上げる。方や定時で帰る。しかも俺の担当手を抜いたら納品できない。
ライフスタイルが違う。おんなじ給料。残業代が出るわけでもない。みんななかよくしなさいって言われても限界がある。
それが、みんなのいう頭のいい人の扱いだよ。もうイヤだって思った。
さすがに仲良くできないよ。仲良くしたら心も体も病気になっちゃう。
頭いいから簡単だろ。やってくれよがどれだけ人を傷つけるかというケースを すこし誇張して書いたよ。
元の議論についてはartonさんが書かれた日記エントリで見事に昇華されていると思う。以下は俺が気付いた雑感。
最初の一発ドン！ の開発にカネがかかるのはしょうがない。設計ができるエンジニアが必要だ。
しかし、その後のメンテに、そんな単価の高いエンジニアを張りつけるわけにはいかない。できれば可能な限り単価を下げたい。そこでこんな発想が出てくる。
「ソースコードの内容がきちんと説明された詳細設計書があれば、他人のソースコードを読むことさえできないようなライトオンリーエンジニアでもメンテできるんじゃないか？」
どうもそういう発想で、業界の一部は動いているのではないか、という気がする。当然コードをちゃんと読んで手を入れてるわけではないから、いつか破綻するわけだが……
nao0990
設定が十分に練られていないから、一浪で大学入学して大学二年生修了後さらに二年休学の時点で22歳、なんていう基礎的な矛盾が起きるのだ。
普通に凡ミスでした、すみません。その時点で23歳ですね。他にもおかしい点があるかもしれませんが、記憶違いや身バレを恐れての改変が混ざったためと思って下さい。
nekora
一応事実として書いているので、言語だけで見るとショボい経歴ですがそのまま書いています。VB6 については弁護出来ないレベルの古さなので、格好悪いと言われるとその通りですが、それも含めて仕事をしようと思えればできる、と捉えて頂ければ幸いです。もちろん、古い言語の悪い部分に甘んじて低い技術レベルのままで仕事をしてもよいと言っているわけではありません。
htnmiki
語りたい病ですね
augsUK
今が勝ち組なのかよくわからんとか設定が杜撰だとかいろいろあるけど、想定Q&A作ってまで語りたいんだなあということはわかった。もう少し勝ち組設定の方が良かったと思う。
語り寄りになってしまってすいません。事実ベースで書くことにこだわり過ぎました。
大学中退やその他のハンデがあったとしても、場所／労働条件（給与、福利厚生）／企業のブランドなどへのこだわりを必要以上に持たずに捨てて視野を広げ、自分が必要とされるであろう企業に絞ってエントリーすれば数十社もエントリーしなくても内定はもらえます。なので頑張りどころを間違えずに頑張ってほしいです。
以下はこの一言に対する補足説明となる、背景や就職活動の指針についてです。
Twitter / s_suneco: これリクナビのトップだけど、これ私がおかしいというよりは周り ...
https://twitter.com/s_suneco/status/448665586222899201
高校に上がったくらいから就職ということを少しずつ意識するようになり、上記のような何十件もエントリーしなければならない熾烈な就職活動があるという話を聞いて、まだぺーぺーの学生でありながらもそんなのはおかしいと思っていた。学歴は確かに一定の修学を積んだという証明になるかもしれないけれど、企業はそれだけではなく採用希望者の人となりもきちんと見て、共に働くものとして十分な経験、知識、学習意欲などを持ち合わせているものをきちんと採用してくれればいいのにと思っていた。（働いてから採用する側になって、その難しさもまた分かったのだけれど。）
自分の能力は客観的に見て高いのか低いのかは分からないけれども、少なくとも学歴に関しては大学中退という傷物でありピカピカの新卒に比べると人材としての価値は低かったと考えている。そんな自分の足跡をここに記して、一般的な人材像とされている新卒でなくとも、その他諸々の身分であったとしても、落ち着いて丁寧に就職活動をし、こうして就職が出来ているということを知って就職活動の励みとしてもらえればと思う。
結局の所、労働者として働きたい僕らはお金が欲しいというのが企業と同様に前提条件なのであって、そこから
という流れが導き出せると考えています。
自分が学生であった当時もそうですが、そういった流れがあるとこまでは分かっても各点の具体的なイメージは出来ず、企業がどうやって稼いでいるか、従業員はどういった業務を行って給与を得ているかなどを適宜調べたり、諸先輩方に会う時などに質問するなどして一つ一つを自分なりに具体的にしていきました。そうして自分なりの芯となる考えを持っておく事で、無鉄砲に企業に当たるのではなく少しずつ焦点を絞りながら就職活動をし、数社のエントリーのみで内定を頂く事ができたのではないかなと考えています。
うまくまとめられたかは分かりませんが、ここに記した自分の経歴や考え方を見て何かしら参考にしてもらえれば幸いです。
経歴にも書いていますが自分の場合は理系→プログラミングという分野で活動していますので、別の分野（業界、業種、業態）では参考にならないということもあるかもしれません（分野によっては数十社へのエントリーを行った方が確率が上がる、など）。逆に言えば、踏み込む分野によって適切な就職活動の方法というのはあると思うので、それぞれの分野の現職やその周辺の方々の情報をうまく集めて、適切な方法で活動していってもらえれば自分が望む方向に近い所へ向かって行けるのではないでしょうか。
就職活動中の皆さんが無理をせずに向かいたい方向へ努力して向かい、その努力が報われる事を祈りつつ。
