「ライブラリ」を含む日記 RSS

はてなキーワード: ライブラリとは

2017-03-18

愛海「紗南ちゃんご機嫌だね?」

紗南「タルキール龍紀伝が150円だったから買ってきちゃったよー」

愛海「ブードラできる? ブードラしたい! あつみ! ブードラ! すき!」

紗南「お、おう、なんか幼児化してるね。ごめんね、ブードラできるだけは売ってなかったや」

愛海「ならパックウォーズだ!」

紗南「リミテッド好きなの?」

愛海「うん、一期一会感がなんともいえないよね」

紗南「よおし、じゃあ、お互いに基本地形を全種三枚づつ用意して……

ぱっくむきむき!」

愛海「むきむき!」



紗南「デュエル!」

愛海「デュエル!」



紗南「1D20、5!」

愛海「10。じゃあ7枚ひくよ」

紗南「あたしも7枚ひいて、うーむ土地が……」

愛海「むふふー、あたしも土地がだけど、けどこの一期一会感を楽しむのがパックウォーズだよ!

山おいて、エンド。おやまよ、あたしにちからを!」



紗南「じゃあターンもらって、アンタップアップキードロー、メイン入って、森でエンド」



愛海「うおおおお! おやまどろー!

島! えっんどだよー」



紗南「平地、うーん平和マジックだなあ、エンド」



愛海「だねー、ドロー、ありゃ土地が止まっちゃった、なら、山から赤だして

ラガンの嵐唱者をだっしたっいなー!」

紗南「そらまあ通るよ、速攻かあ殴ってもいいよ」

愛海「ふおおお、なんかえっちいね、なら速攻で殴って」

紗南「はいはい、19」

愛海「えっんどだよー」



紗南「ドローして、山置いて、フルタップ変異をだすよ!」

愛海「いくら島が立っててもカウンターはないねー」

紗南「エーンド」



愛海「ターンもらって、森出して。変異かー、2/2なんだよね?」

紗南「うん、裏向きは基本的に2/2だね」

愛海「じゃあ、山と森をタップして、双雷弾、その変異に2点だよー」

紗南「ぐぬぬ、除去られるね、ちなみに砂嵐突撃者だったよ」

愛海「表になるとカウンターのって、4/5かあ、大きいね

まあでも、嵐唱者で殴って、エーンドエーンド」

紗南「18」



紗南「ドロー、できることがないなあ、沼でエンド」



愛海「嵐唱者無双な感じだなあ、ドロー

森だして、島と森と森をタップで、

微風の写字官、ルーターだよ、リミテッドルーターは強い!

しか呪文唱えればアンタップ

嵐唱者で殴っておしまい

紗南「17、確かに手札の質を高められるのはいいよね」



紗南「あたしもなんかこい! ドロー

森だして、うわーん、できることはあるけど、しても意味ないなー、

エンドー」



愛海「紗南ちゃんまず呪文すら唱えれてないもんね

けど、これも勝負だよ! ドロー

タップして、写字官起動!

サルカン凱旋すてて一枚ドロー

紗南「えーと、なになに、捨てたのはドラゴンサーチかあ。いいじゃん、唱えてみれば、写字官のアンタップも誘発するし」

愛海「えーでもさあ、パックウォーズなのにサーチするためにデッキちゃうのもったいなくてさー

山出して、森と山タップして、

林間の見張り! 3/3防衛だよ

嵐唱者で殴って、エンド」

紗南「16」



紗南「げーーーまーーどろーーーー!

ぐぬぬぬ、マナが、マナが!

エンドだよー」



愛海「よおし、かっつぞー

ドロー

タップして、写字官起動! 島捨てて、一枚ドロー

平地だして

嵐唱者で殴って、エンド」

紗南「15、いやあパワー1で助かるね」



紗南「ドロー、きたーーー!

きたよ! きたよ! 島!

島! 平地! 森! 森! の4マナ

卓絶のナーセット! プレインズウォーカーだよ!」

愛海「おおおおおお! すごいね! すごいね!」

紗南「さっそく、忠誠度+1能力をつかうね! ライブラリの一番上を見て

見て、満足! エンド!」

愛海「紗南ちゃんのそういうところかわいいね」



愛海「ドロー、ナーセットさんは、忠誠度7かあ、高いなー

写字官もそろそろ殴った方が良さそうな気もするけど、あたしはカードを引きたい!

島をタップして、写字官起動! 島捨てて、1枚ドロー

沼出して

嵐唱者で殴って、エンド」

紗南「14」



紗南「ここから、あたしのマジックが始まる!

3マナだして、変異

さらに、ナーセットのプラス効果

チラ見して、見るだけエンド!」

愛海「仕事してなくない?」

紗南「いいの!」



愛海「さて、やっとクリーチャーも出てマジックらしくなってきたかな、

ドロー、島タップの写字官起動して、ドローして

タップしいの、よろめくゴブリンだしいの、

エンドしいの」

紗南「なにその、しいの」



紗南「ドロー

島だしてー

ナーセットのプラス能力

よし、手札に衝撃の震えだから、手札に加えるね」

愛海「クリーチャーが場に出るたびに1点かあ、どうなんだろうな」

紗南「どんどんいくよ、島を残して、緑がらみの6マナ

高楼の弓使いを大変異! 4/5だーーー!」

愛海「でかーーーい」

紗南「なぐる!」

愛海「16!」



愛海「ドロー

何気に、次のターンナーセットが奥義かあ

写字官、よろめくゴブリン、嵐唱者でナーセットなぐるね」

紗南「忠誠度は5だね」

愛海「第二メインで、予期!

ううん、これを加えて、残りを下に戻して

あたしも変異!」

紗南「だすねー」

愛海「ドローたくさんしてるからね」



紗南「じゃあ、ドロー

ナーセットのプラス

チラ見して戻して

赤がらみ2マナで、衝撃の震え! これであたしがクリーチャーを出すたびに愛海に1点だよ

さらに! 島残してタップして、青からみの4マナ! 若年の識者! 2/2だけど、死ぬとき2枚もドローできるよ!

衝撃の震えが誘発するね」

愛海「15、あれー、ライフがいつのまにか近づいてるね」

紗南「ナーセットのおかげだね、高楼の弓使いでアタック! 大変異から、4/5だよー」

愛海「防衛の人がいるんでけど、ここはブロックしなくて、11

紗南「よおし、ライフも逆転だ!」



愛海「ドロー

防衛の人以外の全員でナーセットにアタック! 6点だよ」

紗南「ぐぬぬきっかりでナーセットは墓地だね」

愛海「エンド」


紗南「ドローして、山だしてー、王楼の弓使いと識者で殴るよー」

愛海「弓使いは林間の見張りでブロック、見張りちゃんばいばい、残り9」

紗南「識者が死んで欲しかった」

愛海「しょうじきだなあ」



愛海「ドロー

平地!

そして、白絡み3マナダブルシンボルは重い!

アラシンの先頭に立つ者! 二段攻撃の2/2だよ! 二段攻撃付与戦士がいないか意味なし!」

紗南「結構大きいね

愛海「召喚酔いの先頭に立つ者以外の全員でアターーーック!

6点だよ!」

紗南「残り8! 終わりが見えてきたね」



紗南「けど、ナーセットとの絆があたしを強くするよ!

ドロー

2マナで、シルムガルの手の者! 接死の2/1!

衝撃の震えの誘発!」

愛海「残り8!」

紗南「……ここは、なぐるよ! 弓使いと識者でパンチ、6点! エンド!」

愛海「残り2!!!



愛海「ドローして……

あたしも全員でパンチ

全部通れば10点!」

紗南「接死で二段攻撃の人をブロック! これで、ダメージは6点だから、2点あまるよ!」

愛海「ならあたしも大変異!!!

盾を持つ守護者! +1/+1カウンターをばらまくよ! 写字官と守護者において、通るダメージは8点だああああ!!!

紗南「緑がらみ3マナ暴露する風! このターン戦闘ダメージをすべて軽減だよ!」

愛海「えええええええ!!! な、なにそれ!」

紗南「ナーセットがあたしにくれたんだ」

愛海「いや、ナーセットの効果でめくって手札に加えたの衝撃の震えだけじゃ?」

紗南「いいの!」

愛海「もー、なにもできないね、エンドだよ」



紗南「じゃあ、ドローして弓使いでなぐって」

愛海「うわーん、私の負けだねー、ありがとうございましたー」

紗南「ありがとうございました」



愛海「リミテッドはたのしいねー」

紗南「ナーセットちゃんかわいい

愛海「紗南ちゃん、さっきからそれしか言っていないね

紗南「ナーセットちゃんのお山さわりたい」

愛海「あたしのキャラとらないでよ! キャラじゃなくて本心だけども」

紗南「ナーセットちゃんとナヒリさんの間に眠りたい」

愛海「ナヒリが巻き込まれ!?しかに白青赤でジェスカイカラーだけどさあ」

紗南「ゲートウォッチに対抗して、おやまウォッチを結成しようよ」

愛海「だから、それあたしの個性なの!」

紗南「おやまウォッチの誓いは、手のひらを見せるんじゃなくて乳首

愛海「あたしでもそんなこと言ったことも思ったこともないよ」

2017-03-11

ライブラリアップデートしたら壊れたって

最近はbreaking changesがあるかどうかも確認しないでアップデートすんのか?

進んでるねー(後ろに)

2017-03-05

コメ率の低いはてブエントリ英語エロか?

http://anond.hatelabo.jp/20170305115905増田以外のホットエントリで見ると。

2017年2月コメント率の低いホットエントリ

コメント タイトル コメント数/ブクマ ブクマページ
0.0% Python3.6 から追加された文法機能 - Qiita 0/96 b.hatena.ne.jp/entry/324476241
0.8% 文章ベクトル化して類似文章の検索 - Qiita 2/245 b.hatena.ne.jp/entry/324662835
1.0% [wip] 会社サーバサイドエンジニアにReactとかReduxのことを説明する資料 - Qiit 1/97 b.hatena.ne.jp/entry/319535213
1.1% 機械学習ディープラーニングの入門者向けコンテンツまとめ - Qiita 1/94 b.hatena.ne.jp/entry/321793279
1.9% Web制作時の概算費用と想定納品日を簡単に計算する票をつくってみた – のんびりデザインしているよう 7/375 b.hatena.ne.jp/entry/320010979
2.0% 最近見かけるレイアウト・ナビゲーション・スライダーフォームなどがどうやって実装されているのかのまと 7/344 b.hatena.ne.jp/entry/322198623
2.2% フロントエンド知らない私のwebpack入門 その1 - Qiita 4/186 b.hatena.ne.jp/entry/319233247
2.3% フルマネージドのSaaSクラウドデータベースサービスdashDBの活用スタイルとは ~手間いら 5/216 b.hatena.ne.jp/entry/323891713
2.4% Pythonをやるときに参考になりそうな情報 - のんびりSEの議事録 19/807 b.hatena.ne.jp/entry/322300431
2.5% React基礎 · GitBook 17/681 b.hatena.ne.jp/entry/321494522
2.7% 開発効率を上げるテスト設計 // Speaker Deck 5/183 b.hatena.ne.jp/entry/323584734
2.8% 畳み込みニューラルネットワーク可視化 - 人工知能に関する断創録 3/108 b.hatena.ne.jp/entry/322431100
2.8% グランブルーファンタジーを支えるインフラ技術 // Speaker Deck 10/359 b.hatena.ne.jp/entry/324611754
2.9% 仮想DOMの内部の動き | プログラミング | POSTD 6/206 b.hatena.ne.jp/entry/321289144
3.0% 金融データPythonでの扱い方 - 今日も窓辺でプログラム 16/527 b.hatena.ne.jp/entry/322842311
3.1% Python Jupyter notebookでpandasを使いCSVを読み込みグラフを描画してp 5/162 b.hatena.ne.jp/entry/321556884
3.1% React Redux Real World Examples 〜先人から学ぶReact Redux 9/290 b.hatena.ne.jp/entry/323749846
3.2% Awesome Python:素晴らしい Python フレームワークライブラリソフトウェア・リ 15/472 b.hatena.ne.jp/entry/319013267
3.2% 履歴書志望動機|最速で書く方法と受かる書き方 14/433 b.hatena.ne.jp/entry/279613157
3.4% 今日からはじめるGitHub初心者がGitをインストールして、プルリクできるようになるまでを解 38/1128 b.hatena.ne.jp/entry/318690305
3.4% スケーラブル GCP アーキテクチャ 6/178 b.hatena.ne.jp/entry/322723492
3.5% アーキテクチャから新しい! 初めてのエディタには、21世紀生まれの「Atom」がおすすめ【続・若手エ 11/311 b.hatena.ne.jp/entry/322534650
3.5% フロントエンドの基礎知識 // Speaker Deck 15/423 b.hatena.ne.jp/entry/322749937
3.7% ロードバランサー再入門 | ツチノコブログ 26/704 b.hatena.ne.jp/entry/323163487
3.7% APIサーバを立てるためのCORS設定決定版 - Qiita 5/134 b.hatena.ne.jp/entry/321742626
3.8% 画像】こんなのソフマップじゃないwwwwwwwwwwwwww|ラビット速報 5/131 b.hatena.ne.jp/entry/321219627
4.0% 動画あり】人志松本のゾッとする話のあるある探検隊の話怖すぎwwwwww | 2ちゃんねるスレッド 10/252 b.hatena.ne.jp/entry/319507149
4.0% 翻訳2017年展望: pandas, Arrow, Feather, Parquet, Spa 7/176 b.hatena.ne.jp/entry/324411617
4.2% 【たまに行くよ!って人向け】いつもと少しちがう東京ディズニーシーデートにするための5つの方法 @ja 3/72 b.hatena.ne.jp/entry/321496344
4.3% 高速なシステムを作る方法 // Speaker Deck 9/211 b.hatena.ne.jp/entry/283448858
4.3% 処分・廃棄にお金は要らない!?パソコン無料引取してくれる業者一覧 7/162 b.hatena.ne.jp/entry/320803373
4.3% タデサプリを支えるデータ分析基盤 ~設計の勘所と利活用事例~ 3/69 b.hatena.ne.jp/entry/322583838
4.4% 「Front-End Developer Handbook 2017」がGitBookで無償公開。フ 24/542 b.hatena.ne.jp/entry/318947145
4.6% デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi - 元RX-7乗りの 7/152 b.hatena.ne.jp/entry/322562611
4.6% 大量の要素を高速に表示するためのバーチャルレンダリング入門 / Virtual Rendering 6/130 b.hatena.ne.jp/entry/323604383
4.7% MySQLアンチパターン 22/473 b.hatena.ne.jp/entry/319218778
4.7% 5年間コードを書き続けたエンジニアが、新人に読んでもらいたい11冊+αを紹介する - エンジニアHu 47/1006 b.hatena.ne.jp/entry/313934939
4.7% グーグル社員も長友選手も行う集中力を高める方法 - 自分で学ぶ心理学 20/427 b.hatena.ne.jp/entry/322090614
4.8% 例の機械学習コースが良いらしいと知りながらも2年間スルーし続けたがやはり良かったという話 - Qii 68/1418 b.hatena.ne.jp/entry/321403591
4.9% NoSQL を使用する場合と SQL を使用する場合Microsoft Docs 28/577 b.hatena.ne.jp/entry/322834020
4.9% Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita 5/102 b.hatena.ne.jp/entry/321629987
4.9% 誰でもできる、プレゼンが劇的にうまくなる基本テクニック - 科学非科学迷宮 77/1557 b.hatena.ne.jp/entry/318913434
5.0% 脆弱性発見者が注目する近年のWeb技術 // Speaker Deck 24/481 b.hatena.ne.jp/entry/319516657
5.1% たった3つのコトで仕事が楽になる!「できる上司の会議」がマジで真似したい | CuRAZY [クレイ 7/138 b.hatena.ne.jp/entry/322534334
5.1% 日経電子版を支える基盤API // Speaker Deck 13/256 b.hatena.ne.jp/entry/319592914
5.1% 30歳から始める数学 - Shoyan blog 50/982 b.hatena.ne.jp/entry/323617832
5.1% インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話 - VOYAGE GRO 20/392 b.hatena.ne.jp/entry/323171376
5.1% 『How to Get Startup Ideas』 - いかスタートアップアイデアを得るか - 17/333 b.hatena.ne.jp/entry/324384439
5.1% 無料ウェブサイトブログに使える写真を検索可能な28サービスまとめ - GIGAZINE 18/350 b.hatena.ne.jp/entry/323600897
5.2% 内向的な人のための面接ガイド - GIGAZINE 14/271 b.hatena.ne.jp/entry/322036523

Pythonデータベース関連が目立つ。コメント無しで96ブクマに達するPythonさん凄い。マウンティング心?を刺激しないのだろうか。炎上したくない人はインデントに気をつけながらオブジェクト指向で書くといい。



2017年2月コメント率の高いホットエントリ

コメント タイトル コメント数/ブクマ ブクマページ
74.5% はてブ要望「返信出来るようにして欲しい」 - interact 114/153 b.hatena.ne.jp/entry/319990286
73.5% あなた朱雀とか白虎とか四神を覚えたキッカケは何?」という質問に対し世代がバレそうになる人々→「幽 319/434 b.hatena.ne.jp/entry/322198765
67.8% 内海 聡さんのツイート: "あなた甲殻類アレルギーだった場合あなたの心は殻に閉じこもっている可 449/662 b.hatena.ne.jp/entry/318821783
67.4% 日米首脳会談 首相は「ドラえもん」のスネ夫になった!民進党野田幹事長が批判 (産経新聞) - Ya 95/141 b.hatena.ne.jp/entry/321930776
65.7% いい記事書けばブクマつくとか嘘っぱち!こんな嘘がまかり通るはてな界に物申すっ! - ゆるくいきていく 260/396 b.hatena.ne.jp/entry/323206934
65.5% 痛いニュース(ノ∀`) : 梅沢富美男(66)、老害判定に怒り 「日本は俺達が作ったんだぞ!」 - 190/290 b.hatena.ne.jp/entry/322785094
65.5% 茶碗に米粒を残した状態で「完食」する人は完全悪ではないけど相容れられない、という話に意見続々 - T 413/631 b.hatena.ne.jp/entry/321479096
64.6% けものフレンズを視聴1分30秒で挫折。 - 自由ネコ 122/189 b.hatena.ne.jp/entry/321589678
63.7% けものフレンズコスプレ批判に対する異論まとめ - Togetterまとめ 228/358 b.hatena.ne.jp/entry/323622485
63.6% レジでバレる!二流の人の超ヤバい3欠点』という東洋経済記事を読んで。クレジットカードイメージ 119/187 b.hatena.ne.jp/entry/323599229
63.5% 痛いニュース(ノ∀`) : 日本在住のイスラム教徒の子どもがハラール対応給食に苦慮→学校側に配慮 290/457 b.hatena.ne.jp/entry/321128745
63.0% あざなわさんの炎上はてな村権威のなさ - メロンダウト 133/211 b.hatena.ne.jp/entry/323813866
62.7% プレミアムフライデーって何でこんなに叩かれてるんだろう? - シャイニングマンの「勇気を君に」 126/201 b.hatena.ne.jp/entry/324113658
62.5% 飯田譲治さんのツイート: "日本が悪い日本が悪いって、民間人は殺さないってルール破って、原爆落として 65/104 b.hatena.ne.jp/entry/321434534
62.4% 偏差値40の大学日本必要なのか?子供を焼き殺す大学補助金は不要 - カキカエブログ 166/266 b.hatena.ne.jp/entry/318786744
62.2% 坂上忍 清水富美加の月給5万円は正当「僕らの時もそうだった」 (デイリースポーツ) - Yahoo! 237/381 b.hatena.ne.jp/entry/321888913
61.9% 清水富美加17日著書出版「全部、言っちゃうね。」 - 芸能 : 日刊スポーツ 73/118 b.hatena.ne.jp/entry/322431771
61.5% 警視庁捜査1課長が竹刀で23歳美人記者ボコボコ (文春オンライン) - Yahoo!ニュース 415/675 b.hatena.ne.jp/entry/322218394
60.7% ゴルフに興じる首相、誇れない」民進・蓮舫氏:朝日新聞デジタル 136/224 b.hatena.ne.jp/entry/321608217
60.6% 金があるのに、理屈をつけてコンテンツに金を落とさない」連中について - うらがみらいぶらり 243/401 b.hatena.ne.jp/entry/321324226
60.6% 痛いニュース(ノ∀`) : 中学校で「やばい」という言葉を使用禁止に 若い世代意味多様化 - ラ 132/218 b.hatena.ne.jp/entry/324642052
60.3% 受動喫煙対策東京だけでやれ」 自民党内で反対論噴出:朝日新聞デジタル 241/400 b.hatena.ne.jp/entry/321316384
60.1% 娘の卒業式用の服を買いに行ったら驚愕した - コバろぐ 92/153 b.hatena.ne.jp/entry/321299915
60.1% 「洗剤いらず」スポンジで教頭などが児童の体こすりけがNHKニュース 215/358 b.hatena.ne.jp/entry/322584234
60.0% 松井一郎さんのツイート: "長谷川さんが、ブログで伝えたかったのは、健康であるための自己管理重要 201/335 b.hatena.ne.jp/entry/320414066

2017-03-04

http://anond.hatelabo.jp/20170304155913

実際のところ、もう殆ど業務ライブラリ習得具合次第だから

最前線でやるのでなければ技術力なんて求められていない

しろ今の若い人が歳とって何ができるのか考えると結構悩ましいよね

簡単サービス終了できる時代から

http://anond.hatelabo.jp/20170304134654

そうは言っても、老眼や体力の低下、集中力の低下は避けられないし、

40過ぎて現役してても、若手からコーディングスタイルが古いとなじられたりしている様子をまじかにみてると、

本気のプログラミングは35歳に限界があるのも理解できるんよね。




ただ、一方で、プログラミングライブラリの充実化に伴って、圧倒的に短いコード必要な処理を賄えるようになりつつあるので、

とっくに定年過ぎた爺さんプログラマーjquery有用性を熱く語っていたときは、生涯現役という生き方もあり得るなとは思った。

2017-03-03

フォルダの隅積まれフリーゲーム

STEAMライブラリも3桁後半。

どうしろってんだ。

SWITCH買うのは我慢したけどそんな事したからって積まれゲームが一気に減るわけじゃない。

どうしろってんだ。

2017-02-26

http://anond.hatelabo.jp/20170226153940

自動化って

暗黙知をなくす作業でもあるなぁと思った。



Ansibleとかはサーバー構築手順書をなくすことができるし、mavengemなどのパッケージ管理ツールセットアップ手順の暗黙知をなくすことができる(なんのライブラリ入れるーとか)



人にあれこれ聞くより、コード見て大体わかるような感じになっているとすごく助かるんだよなぁ。

もしかしてそういう感じで仕事を続けていけば、英語圏とかでも仕事できるようになるのかなぁ。



vagrant up ← コレだけで開発環境揃う環境、素敵に開発に入りやす



わしが1年1人でやっているやつ、ミドルウェア系には秘伝ミソが少し出来ているから、dockerで全部揃うようにしてみるかなぁ。Solr使っている部分とかしょうがないような気もしつつ、ローカルにあったほうが良いんだろうなぁ。あんま頻繁に開発しないし、そこは自分でやればいいか・・・。まあ多分solrコンテナを立てれば良いんだろう。

anond:20170225195916

"Google翻訳オープンソースプロジェクトに使うのはダメなのか? " についての反論

いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。

GPLコンパイラの例

このGPLコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。

確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェア著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。

ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。

詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。

https://www.gnu.org/philosophy/free-sw.html

ほとんどの自由ソフトウェアライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアライセンスは、契約を元にするもので、契約もっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。

わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンス利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由である結論づけるかもしれません。

また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフト保護されたソフトウェアでも、それによって作成された著作物GPLにならない(つまりコンパイラやパーサーのライセンス継承しない)ことを根拠考察しているようだが、実はbisonやGCCGPLにはライセンスに対する例外付属していることを考慮すべきである

GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアライセンスが影響しないことを確実にするためにこれらの例外規定しているのではないか

この二つの理由から、元記事議論世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。

フェアユースについて

フェアユース規定は例えば日本では存在しない、

加えて言えば、たとえフェアユース規定が全世界的に利用できて、営利目的でなければ利用できたとしても、

フリーソフトウェア/オープンソース定義の中に

自由.0: どんな目的に対しても、プログラムを望むままに実行する自由

(i.e. オープンソース定義 6項 利用する分野に対する差別禁止)

がある限り、そのような制限ディストリビューションは受け入れられないだろう。

またOracle vs GoogleJavaAPI訴訟はケースとしてはかなり特例であり、

一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、

これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である

というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである

Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーコンピューター計算コントロール

つべであるという自由ソフトウェア思想と明らかに相容れないものである

このようなサービスを利用することの弊害として、(例えば)Google翻訳翻訳処理の計算依存することにより、ユーザー入力Googleが常に把握することが挙げられます

もちろんこれはあまり良いことではない。

多くのFLOSSシステムディストリビューション自由ソフトウェアを主に入れるというガイドラインを持っている。

アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、

これは事実上妥協産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者異論を挟まないだろう。

また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物依存する場合、contribというセクションに閉じ込めており、それは公式システムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)

Ubuntuコミュニティ新規に作られた著作物コミュニティ哲学に反する物に依存するというのは、かなり致命的である

たとえ奇跡が起こり、例外的Google翻訳や一部のプロ翻訳ツールBSDライセンス(Launchpad上での翻訳ライセンス)での出力を許したとしても決して褒められたものではない。

Ubuntubug#1に"Ubuntuソフトウェア自由である。常にそうであったし、今後も常にそうである自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである

https://bugs.launchpad.net/ubuntu/+bug/1

この反論を読んだ読者の中にはあまりGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、

いわゆる"Linuxディストリビューション"の中には数多くの重要GNUソフトウェアシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)

またUbuntu派生元となったDebianの成立経緯にはやはりFSFが関わっている。

さらに言えば、システム保守を手伝う人の中にはシステムフリーからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)

のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。

追記

Ubuntu Japanse Teamの関係者に読まれたようなので満足しました。(2017/2/27 22時)

2017-02-12

https://docs.python.org/2.7/library/urllib.html#module-urllib

See also. The Requests package is recommended for a higher-level HTTP client interface.

ならこんなクソみたいなモジュールを標準ライブラリにしてないでバンドルしろよ、そっちを!

2017-01-24

http://anond.hatelabo.jp/20170124234323

そういう輩は、合成音声になったところで、

音声ライブラリ愛称つけて、その名前で呼ぶことになるだけだと

おもうけどなあ。

2017-01-23

anond.hatelabo.jp/20170123113224

昔のmacゲームMarathonって言うFPS(ショボいけど)は好きだった。

地球人兵士として優れているので、主人公地球人は仮死状態で保存され、

何かある度にに蘇生され、人工知能から指令を受けるんだけど、

「また、それとほぼ同時に衛星軌道上の〇〇も破壊されました

(これは私の光学機器観測しました)」

とか

「新しい体制の中で彼らが生き延びる場所はないと私は判断しました」

とか。

無料で公開されたライブラリとかあるみたいだけど、やり方はよくわからないです…




余談だがオカルト界では、AI人間を超えるってのは、特異点 シンギュラリティって言って

それがいつなのかが割と話題らしいが、囲碁で総当たりみたいなことをやったAIが、

人間に勝ってる時点で、もう人間の"セオリー"みたいなものは時期に用済みになるのでは?

と言ってる友人もいる。




更に余談だけど、楽園追放をあげてる人がいるなら、シリーズ物アニメだけど、

serial experiments lainもアリかと思う。人によってあれが何の話なのかは

随分意見が分かれるけど、それ自体主題のようなアニメなんだと思う。

ひと昔もふた昔も前の人が見た、現実とは異なった未来の話って感じかも知れないけど。

2017-01-22

ownership とシステムプログラミングその他に関する怪文書

この会話ログフィクションであり、実在人物地名団体とは一切関係ありません。

坂木

わろた

Rust vs. Go に対する @tanakh さんの発言まとめ

https://togetter.com/li/1072495

坂木

自分理解できないもの意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原

NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん

宮森

今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森

……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原

いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さなコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.

宮森

いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意

安原

いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないか危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.

宮森

あ、それはそうだと思います概念を獲得していない

リソース人間管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原

OpenSSL騒動の時,関数の途中で return したことによるリソース漏れ揶揄したことがありますOpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.

安原

ああ,はい人間を信頼しすぎているというのはいかにもありそうですね.

藤堂

C++er の方がその辺もっときちんとしているように見える

安原

しろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.

宮森

シニア開発者しかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森

OSとかシステム系のプログラマの人々、基本的リソース人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木

[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井

自分が知っている C 「しか」書けない職業プログラマ基本的地雷だなぁ...。

今井

リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原

うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理必要になる場面少ないし…….

坂木

コード品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原

OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コード品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.

宮森

そこはコードレビューテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木

品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井

あとは、デモが作れればいい、的なのも同じかなぁ。

宮森

メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森

メモリ管理コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原

OSGC してくれる論, TPO をわきまえているならば普通にありですよね(TPO をわきまえているならば!).

今井

まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木

私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井

あれ、そうなんです? 私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。

(つまり、ここから坂木さんのハードルめっちゃ高いという帰結が...)

宮森

いろいろ言っていますがワタクシ、そういう管理必要プログラムは全く書けなくなりましたので今書くと死にますプログラム顧客大事データが)

安原

しかし,システムプログラミング界隈に「人間リソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?

宮森

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森

実際、Linuxカーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれ気持ちも分かる。

宮森

他の言語OS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木

Linux カーネル、一体どうやったらあの規模のコードクオリティコントロール出来るのか本当に不思議

安原

Linux カーネルのアレは,属人性依拠しすぎていて全然スケールしないのでは…….

坂木

Linux カーネル属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバいレビュアーごろごろしているのかな

宮森

属人性依拠しさえすればできるので十分な数の開発者がいれば問題になりません(キリッ

安原

私も [検閲削除] のコミュニティを見てましたから,各々必要ドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡アンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡しかないと思っています

宮森

つーても機械エンジニアリング町工場職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森

なおその対極がみずh(省略されました

安原

Linux カーネルにおけるスケール云々は, Linux カーネルコミュニティ自体におけるスケーラビティではなくて,(システムプログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.

坂木

まあ人外を集めるという手法一般にはスケールしないですからね……

宮森

C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….

坂木

Rust は 1.0 が出る直前くらいにちょっと触ってイテレータが作れなくて敗北したっきりだな。

坂木

イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……

藤堂

1.0 以前のことは忘れましょう (本当に unstable)

安原

Rust,型でエラーを弾くだけではなくて質の低いプログラマまでも弾く印象.

坂木

一般に型の強い言語は質の低いプログラマを弾きますね(Haskell などを思い浮かべながら)

安原

「Rust 経験者」という条件でプログラマ募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!

藤堂

犯罪ですよそれは

安原

はい

藤堂

haskell 経験者を集めて php 書かせようとした会社がどこかにあったような (ヘイトけがたまる)

安原

まさにそれをイメージしていました.

宮森

どういう顛末になったか詳しく知りたいw

藤堂

うーん、それ以降の話は知らず

今井

Rust そして誰もいなくなった、にならないかが一番心配だったりする

安原

それな

宮森

もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

2017-01-20

web系が苦手な原因

誰なのかよく分からない人が作ったライブラリ盲目的に取り込むところ

2017-01-14

http://anond.hatelabo.jp/20170114155348

明確な目標があるのに、もったいない

ネットだと、情報が多すぎるのかな

javascriptかな?と思ったけど、ruby

ifもforもでてこなくてスマ

eachが形を変えたforです

いろんなとこからコピペ量産して、2時間近くかかりました^^

api取得はすぐだったけど、json、hash、arrayでごにゃごにゃ)

rubyソース

# ライブラリ
require 'net/http';
require 'uri'
require 'json'

# 検索文字
$q = 'http://ci.nii.ac.jp/books/opensearch/search?q=%E7%B3%9E&format=json'

# web-apiから取得
# https://support.nii.ac.jp/ja/cib/api/b_opensearch
def search(q)
    uri = URI.parse(q)
    json = Net::HTTP.get(uri)
    result = JSON.parse(json)
end

=begin
取得データ1件サンプル
{"title":"糞土",
"link":{"@id":"http://ci.nii.ac.jp/ncid/AN00094249"},
"@id":"http://ci.nii.ac.jp/ncid/AN00094249",
"@type":"item",
"rdfs:seeAlso":{"@id":"http://ci.nii.ac.jp/ncid/AN00094249.json"},
"dc:date":"1953",
"dc:creator":"糞土会",
"dc:publisher":["糞土会"],
"prism:publicationDate":"1953",
"cinii:ownerCount":"8"},
=end

# データ整形
#
# 入力データ構造
# {"@id":"http://ci.nii.ac.jp/books/opensearch/search?q=%E7%B3%9E&format=json",
#  "@graph":[ { "items":[ ,,,
#
# 出力(ハッシュ)
# {title => dc:date ,,, }
def format(hash)
    title_date = Hash.new

    # ハッシュキー"@graph"の値の配列の先頭のハッシュキー"items"のハッシュ配列を取得
    items = hash['@graph'][0]['items']

    # タイトル出版年を取得して、戻り値ハッシュへ追加していく
    items.each do |item|
        title = item['title'].chomp
        date  = item['dc:date']
        title_date.store(title, date)
    end

    return title_date
end

# 並び替え
def sort(hash)
    hash.sort_by do |key, value|
        value
    end
end

# 出力
def print(hash)
    hash.each do |key, value|
        puts "#{value}年 #{key}"
    end
end

# メイン関数
def main
    # web-api検索して、
    result1 = search($q)
    # データを整形して、
    result2 = format(result1)
    # 出版年で並び替えて、
    result3 = sort(result2)
    # 出力する
    print(result3)
end

# 実行
main

rubyスクリプトの実行結果

C:\Users\unko\Desktop\prog>ruby webapi.rb
1848年 人欲辨 (じんよくべん)
1870年 雀糞論説
1920年 青瓷説
1933年 管内ニ於ケル鶏糞ノ利用状況
1947年 糞尿譚 : 小説1953年 糞土
1955年 黒い裾
1955年 形成
1959年 石糞
1972年 糞 : 海田真生個人文芸誌
1972年 乳幼児糞便図譜
1987年 糞尿と生活文化
1991年 皇居と糞尿と大嘗祭 : 皇居「糞尿」裁判を支える会ニュース
1995年 糞袋
2000年 糞尿史 : 遷都は糞尿汚染からの逃避だった
2005年 「糞尿」大全
2007年 糞虫たちの博物誌
2008年 うんちのはなし : う~んとげんきになる
2009年 糞神

2017-01-13

世代交代必要もの

http://qiita.com/jj1bdx/items/a9cd77807e0d689fb4b6


オープンソース活動をまったくしていない僕が勝手に考えた「世代交代必要もの

(若者)

1. 今後、10年(?)はコミットできる「若さ」を持つ

2. メンテナンス継続的に行う「時間」を持つ

3. プロジェクト関係しそうな新しい技術継続的学習する「時間」を持つ

4. 該当プロジェクト以外の活動を行える「時間」を持つ

5. 既存ライブラリの制約を継承把握する「意欲」を持つ

6. メンテナンス継続的に行う「責任感」を持つ

7. 該当プロジェクト継続的に関わり続ける「強い理由」を持つ

(世代交代を望む現役)

1. 若者が失敗から学ぶチャンスを与える「寛容さ」を持つ

2. 若者責任を与える「寛容さ」を持つ

3. 若者が成長してきたときに引き継がせる「寛容さ」を持つ

4. 既存ライブラリの制約・意図を共有できるよう「整理する能力」を持つ

5. 後続が入ってくるようプロジェクトに「魅力を作り出す能力」を持つ

(6). 若者が知りたいときに適切な情報を与える「バランス能力」を持つ

(7). 雑談に走りすぎない「バランス能力」を持つ


大きなコミュニティではないが、1990年に一人の人が立ち上げ、2000年くらいから後続の人と盛り上げているプロジェクトの例を知っている。

ただ、その二人が費やしている時間は、プロジェクトに関する質疑応答だけでも相当な時間を割いている様子が見られる。

後続の人も17プロジェクトに関わっていて、すでに「次の後続」が見つからないとプロジェクト継続は難しいだろう。

上に書いている「必要もの」は健全状態コミュニティ継続されるための条件としている。実際には、時間がないけど頑張ってメンテナンスしているコミュニティは多いと思っている。

2017-01-05

http://anond.hatelabo.jp/20170105195533

IE6の時期に仕事してた俺の頃よりは楽になってると思ったんだが……

JSライブラリが充実してる今でもきついのか。

2017-01-03

日本エンジニアには勘違いしてる人が多い・・

http://www.coppermine.jp/docs/promised/2017/01/closed-some-libraries.html

この人のように自作ライブラリを事前予告なしに公開停止したことを日記に書いてドヤ顔するエンジニアが多い。

アメリカで働いていた頃、同僚に「なぜ日本人に(上のような)多いのか?」という質問をされたが答えに困った。

今にして思えば、そうすることでしか自分存在を訴える手段がないのではと考えられる。「公開停止?どうぞどうぞ」だ。

日本エンジニアの多くは行動原理意識高い系と似ているところが悲しい・・。

2016-12-30

2020年に振り返る2016年Web開発

後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」

先輩「そうかそうか、やっと肩の荷がおりるな」

後輩「これ2016年に作ったシステムなんですよね。僕その頃まだ入社してないんで、最初の方から教えてもらっていいですか」

先輩「よしわかった。環境構築から順を追って説明する」

先輩「まずはじめにnode.jsを入れる」

後輩「あ〜昔流行ったサーバーサイドでJavascript使えるやつですよね。このシステムnodeで動いてたんですね」

先輩「いや、nodeは使ってない」

後輩「え?」

先輩「nodeに付属しているnpmというパッケージマネージャーを使ってる」

後輩「なんでまたそんな回りくどいことを・・・

先輩「当時はnpmが一番メジャーだったんだよ。今主流のN3(N3 is Not Npm)はまだ無かったしな」

先輩「よしnode入れたな。じゃあnpm installだ」

後輩「えい!・・・先輩、なんかエラー出ました・・・

先輩「printFizzBuzzというパッケージが404みたいだな」

後輩「何に使うんですかそのライブラリ

先輩「知らん。依存してるライブラリ依存してるライブラリ依存してるライブラリかなんかだろう」

後輩「バタフライエフェクトってやつですね」

先輩「思い出した。これは昔話題になったやつだ。printFizzBuzzは何かの特許抵触していて非公開になったらしい。

  npm installで落とすのは諦めて、ローカルに残ってるやつで何とかするしかないな」

後輩「それ使って大丈夫ですかね。法的に」

先輩「仕方ないだろ」

先輩「ようやく諸々揃ってBabelやReactやWebpackを使えるようになった」

後輩「それ何ですか?」

先輩「まずBabelだが、これはES2015をES5にコンパイルするツールだ」

後輩「え、なんでダウングレードするんですか?」

先輩「古いブラウザで当時の最新機能を使うにはこうする必要があったんだ」

後輩「なるほど。ではReactは?」

先輩「これは今で言うWeb Componentsみたいなものだな。あと仮想DOM

後輩「Babelじゃダメだったんですか?」

先輩「ダメだったんだよ」

後輩「で、最後Webpackは?」

先輩「リソースモジュール管理して最適化するツールだ」

後輩「最適化サーバー仕事じゃないんですか?」

先輩「当時はモジュールが標準対応してなかったり、http/2もあまり普及してなくてサーバー馬鹿だったんだよ」

後輩「へ〜大変ですね」

後輩「いつの間にかこんな時間ですね。今日まだ1行もコード書いてないですよ」

先輩「一度準備してしまえば、そこから先が楽になるんだ」

後輩「今となっては余計な苦労が増えてるような気がしますけどね〜」

先輩「当時はこれが最善の選択だったんだよ」

後輩「そうなんですね」

2016-12-24

東欧で月給24万円の場合

http://anond.hatelabo.jp/20161222124531

やってみたぜ。

かい事はよくわからなくて悪いんだけど、

諸々引かれて手取りは16万円

嫁も同じだけ稼いでて、家族収入は30万円くらい。子供は二人

生活費は15万円で、家のローンで12万円。

家は、郊外敷地1000平米、住居部分は250平米の5LDKプール付き

車で通勤30分で、毎日10時に出て19時には帰ってくる感じ。

帰って子供の面倒とか家事をやって、22時から26時くらいまでプログラム書いたり

ゲームしたりしてる。職業プログラマー

アラフォーで、フロントからバックエンドiOSアプリAndroidアプリまで一通りやってる感じ

マネージメントはやらないって言ってるからこれ以上給料は上がらないかなぁ。

まぁなんつーか高収入の皆さんまじがんばってw

# 以下24日に追記

確かに貯金はしてないねリアルに月末に貯金額0になる生活だわ。

ただ、医療費用はほとんど無料学費日本で言う小中高は無料幼稚園は二人で5千円位

車とかまとまった金が必要な時は、toptalって言うまぁクラウドワークスみたいなサービス使って

副業で金を調達してるわ。その時は人月6千ドルで請ける上に、毎月末に請求、支払サイト10日みたいな感じだから

一ヶ月半以内に60万円くらいは調達できる。実質一日2,3時間しか働かないけどまぁコード書くのは速いか

今まで文句言われたこと無い。

ただガンガン働いてガンガン稼ぐスタイルは嫌いだから、余りやらないけどね。

そろそろ40で失業したら人生詰むけど、英語と現地語と日本語喋れて、プログラミングも大体最近流行追ってるし、

githubにはスター1000くらい付いたライブラリ公開してるし、まぁこれで食いっぱぐれる事は無いっしょ。

病気になったら死ぬ寸前までコード書き続けるしかいね

家の掃除は、オープンな感じで家具をぐちゃぐちゃ置いていないから楽だなぁ。

庭の落ち葉は超大変だった。

まぁシリコンバレーとか憧れるけど、プログラマーならこういう人生もありまっせ!

12、3年前まで東京で働いてたけど、最近大分改善されたことを祈るわ。まじであの始発の電車みて

一歩踏み出せば楽になれるかなぁってぼんやり思ってた時期は辛かった。

あとまぁ美人は多いね。うちの会社オタクばっかりだから縁はないけどな。

プログラマーは多分外国美女と知り合うとかそういう期待は諦めたほうが良い

子供学校とか行くとリアル金髪幼女がいるぜぉ、お母さんも綺麗w

2016-12-21

しょぼんのアクションスマホアプリ化されている件について調べた

2010年ごろにニコニコ動画上で有名になったしょぼんのアクションってゲームがあるんだけど今どうなってるのか調べてみた。

そうしたらとんでもないことになっていた。

結論から言えばあからさまに怪しいデベロッパー二次配布のソースコードを使って

原作者許可無く勝手スマホゲーにしていた。

itunes.apple.com/jp/app/shobonnoakushon-orijinaru/id894330337?mt=8

サポートURL (工事中扱い)

www.gatobros.com/

play.google.com/store/apps/details?id=com.gorkaramirez.syobonactionhalloween

サポートURL (工事中扱い)

www.pipletas.com/syobon/syobon.html

デベロッパーは『Gorka Ramirez Olabarrieta』というらしい。 ドメインWhoisガード適応済みで情報漁れず。

で、サポートURLのページをよく見るとOpenSource扱いになっていた

Original Source. Ported by @jezng using Emscripten.

sourceforge.net/projects/opensyobon/

Mathew Velasquezと呼ばれる人物が作者に許可無くSourceForgeアップロードしたようだ。

sourceforge.net/u/twoscomplement/profile/

で、SourceForgeプロジェクト開設日が下記のとおりになっているが

Registered 2010-05-16

原作者サイトにはもっと過去の時点でゲームが公開されている。下記のInternet Archiveのもの

wayback.archive.org/web/20091223043445/http://www.geocities.jp/z_gundam_tanosii/home/Main.html

で、問題はここから

このSourceForgeプロジェクト、再配布人が下記のライセンスで公開している。

License GNU General Public License version 2.0 (GPLv2)

www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#DoesTheGPLAllowMoney によると

はいGPLは、誰もが販売することを許可しています。複製を販売する権利自由ソフトウェア定義の一部です。

としている。

SourceForgeに公開されているプロジェクトGPLv2で公開されているので、どうやらスマホアプリとして登場したようだ。

が、まずこれ色々と問題がある

プロジェクトで配布されているソースコード内にはDXライブラリがそのまま含まれているが、規約を守っていない可能性が高い。

dxlib.o.oo7.jp/dxlicense.html より引用する。

<<DXライブラリライブラリファイルソースコードの再配布について>>

 DXライブラリライブラリファイル( 拡張子lib や a のファイル )や、プログラムソースファイル( DxGraphics.cpp や DxLib.h などのファイル )を配布する場合は一部、全部問わず

以下の著作権表記を配布物とともに提供される文書、または他の資料に含めて下さい。

DX Library Copyright (C) 2001-2016 Takumi Yamada.

クレジット表示は探した限り見つからなかった。検証ファイル:SyobonAction_v0.9_src.tar.gz

なお、作者のサイトに商用利用に関する規約が無いとはいえ、さすがに普通に連絡するべきではないだろうか?

(配布ソースコード内には改変可という言葉はあるが商用利用可とは書いていない。)

なお、実行ファイル形式で配布されている物の英語のReadMeには原作者クレジットなし。


どうやらゲームファイルソースコード転載されたようだが、少々違和感がある。

Internet Archive内にあるソースコードSourceForge内のソースコードが違う。

tiku氏のそのまま配布するなを遵守したのだろうか? (配布されているソースコードには日本語が混じっているので非常に怪しいけど)

原作者の動向も分からないし、真実は分からない。

ただ、言えることはしょぼんのアクションスマホアプリとして公開されたのはGPLv2辺りのライセンスになっていたからだということ。

ここまで書いておいてなんなんだけど飽きた。

2016-12-09

から気になってたんだけど。。。

Linux/Unixの開発してるんだけど

GPLソース改変しなくても、ライブラリを静的リンクして配付したら、GPL適用しないといか

という説あるけどホントかな?

そういう説があるんで、上司にいま開発してるやつ、ソースオープンにしなきゃいかんのじゃないですか?

って聞いたら、

ソース改変してなきゃ、GPL適用しなくて大丈夫っていわれた。

GPLってそんなライセンスじゃないよね。


Linux/Unixのの標準ライブラリはかなりGPLが多い。

何も考えずに開発していたら、標準ライブラリ使っちゃうし、

開発している製品GPL適用しなくちゃいか自体って

知らずにいろんなところで発生してそう(特に中小)。

大手はそれなりにチェックしてるだろうけど、

あれだけ膨大にあるライブラリ

全部GPLライセンスかチェックして、

静的リンクしないでorソースオープンにしてるんだろうか?

ちゃんと調査すると、

大手GPL違反はかなり多いんじゃないかなぁ

2016-12-08

ソフトウェアエンジニアは結局地頭なんだなあと痛感している

言語ライブラリフレームワーク担当製品システム仕様会社やチームの原則ルール制度プロセスなど、覚えることが腐るほどある。しか趣味プログラミング受験勉強とは違い、締切がきつい。

あえてたとえるなら「今から一年以内に東大合格してな」レベルの無茶ぶり。物理的に、というか根本的に地頭が足りなくてどう考えても無理ゲー

これをみんな平然とこなしてるのが凄い。ちょっと要領悪い人は残業が多めだけど、残業して何とかなるってのもすごいよね。俺は無理だもん。頭が疲れてくると、それ以上はまともに働かなく(新聞読んでも頭に入ってこないレベル)なる。そんな状態いくら時間かけても先なんて進めない。頭の体力が無いとでも言えばいいか会社の同僚先輩上司はピンと来なかったようだが)。



これでも中学時代からプログラミングで遊んできてて、雑誌載るとか紹介記事書かれるとか収録される程度の結果は出てたし、新人研修とかでも頭2つくらい飛び抜けてたし、今も GitHub で数十 Star くらいなら稼げる、んだけどなあ、今の仕事全然通じない。「Rubyってなんですか?宝石?」とかほざいてた数年前の新人より使えない判定される始末。

結局、地頭なんだよ。俺は地頭が悪かった。みんなは悪くなかった。

ホント、こうもスペックが違うと、色々とバカバカしくなってくるし、特に皆が自分達のハイスペック(というか俺が低いだけだろうが)が当たり前だという前提で進めてくるから腹立つ。上記の新人に「IT会社に入ったのにこんなこともわからないの?」と言ってるレベル。そんなの言ったら問題になるだろ。でも俺の言い分(地頭にも高低があるよ)は通じない。



あー、地頭ほしー。

2016-12-07

http://anond.hatelabo.jp/20161207020046

依存地獄( Dependency Hell )かな。https://en.wikipedia.org/wiki/Dependency_hell

An application depends on many libraries, requiring lengthy downloads, large amounts of disk space, ...

(アプリケーションがたくさんのライブラリ依存していて、長時間ダウンロードや大量のディスク容量が必要で、...)

app depends on liba, which depends on libb, ..., which depends on libz. This is distinct from "many dependencies" if the dependencies must be resolved manually (e.g., on attempting to install app, the user is prompted to install liba first. On attempting to install liba, the user is then prompted to install libb.).

(アプリケーションがAを必要としていて、そのAはBを必要としていて、(中略)Zを必要としているような場合ユーザーが手動で依存性を解決しなければいけない場合には、先ほどの例とは違い、ユーザーは「アプリケーションインストールしようとしたらAが必要と言われ、AをインストールしようとしたらBが必要と言われる」目に遭うことになる)

ログイン ユーザー登録
ようこそ ゲスト さん