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

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

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-06

XCodeについているSwift 3.0について・・・

Swift 2.xと比較して文法やらライブラリ名や扱い方が変わりすぎではないだろうか

Swift 2.x系の入門書を買っていたけど、

あれはどこにいった?

この構文は廃止されてる

とか、できねーことが多過ぎる

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が必要と言われる」目に遭うことになる)

2016-12-05

プログラマー挫折ポイント

モバイルアプリエンジニアだが、最近RailsAPIを作っている

予想通り、ドハマリ連続

 

Rubyでハマる

Railsでハマる

ライブラリでハマる

Aptanaでハマる

AWSでハマる

ネットワーク知識でハマる

DBでハマる

ActiveRecordでハマる

ルーティングでハマる

自分が何でハマってるかわからない

問題の切り分けができない

デバッグ方法が分からない

テストコードなんて書いてられない

ググっても出てこない

問題を切り分けるためにデータを用意して時間がかかる

公式サイト理解できなくて投げ出す

体系だったHowToを読もうとして、その膨大さに死にたくなる

猿でもわかる入門がわからない

一個覚えて、一個忘れる

情報が古くてハマる

途中で間違いに気づいて遠回りする

一個試して詰んで、別の方法試して詰んで、また元の方法チャレンジする

知り合いに聞こうとするが、何を聞いていいかからない

体系立ったHowToを調べるが、自分が知りたいことが何なのかわからない

ライブラリのReadMeとにらめっこする

飽きてはてブを見る

 

考えてみたら、モバイルアプリの方も似た感じだったな

大体2年位ずっとこれをやればいつの間にか慣れてるんだよね

体系だった本から地道に始められる人はすごいと思う

2016-11-28

金融SIer仕事について書きたい

今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田投稿するので少し緊張している。

自分は誰かというと、金融ユーザー子会社に勤めているSEだ。いわゆる1次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。

SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの1つにすぎないものとして読んでほしいと思う。

【私の仕事について】

まず初めに、自分仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、


1.ユーザーベンダー宛てにひたすらメールを返信する

2.エクセルで作ったスケジュールWBS(タスクリストみたいなもの)を広げて眺めている

3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く

4.上司ユーザー宛へ説明する資料作成する。そして実際に説明する


これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルール作成ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。



エンジニアとしての知識について】

同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの3割が情報系、3割が情報系以外の理系、残りが文系といった印象を受ける。

はてなを見ていてWeb業界アプリ業界さらーっとIT系用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。

会社の中のほとんどの人がGitGitHubを知らないだろうし、DockerJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術貪欲でないし、それを使える環境はないし、ユーザー投資しない。

新しい技術基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら?という問いに回答できないケースばかりだからだ。だから、今動いているシステムスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。

誰も、どうしていいかからない、どこから手をつけたらいいかからないのだ。



要件定義について】

じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。

ユーザーユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチもっと金かけてやれよと思うのだが、ユーザーパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。

また、業務内容によってはミスった時のリスクがでかい特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。




やりがいについて】

毎日メールエクセルパワポとにらめっこして、ユーザーベンダーとおしゃべりして、何かやりがいはありますか?と問われると、少しだけあるにはある。

案件規模が億越え、10億とか普通な世界なので、官公庁連携したりと大きな仕事が多い。勝手ゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、

例えば「スカイツリー建設プロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな?と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。




からエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行飲み会写真ばかりだ。

一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキル必要仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的スキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有スキルを身につけてしまって、他社に転職できない状態になるのだが。)


私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。

ただ、私にはミスの許されない超絶大規模プロジェクト精神をヒリヒリさせながら、数百人月プロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。

2016-11-23

[] 再開発された車輪は小回りが利く

ある機能が欲しい時、既存プログラムを拾ってくると一瞬で終わることも多いのだが、

他人が組んだプログラム依存ライブラリやら受け付けない値やら自分では許せない範囲の誤差がある近似が含まれていたりするから

自分で一から組み直すのも悪かないよねという意味

引継ぎをした人間がどうなるかは知らない。

2016-11-20

大多数のプログラマは…

IT業界に努めてもうそろそろ二桁年。

そこそこの企業特にWeb系で渡り歩いた経験から真実を書こう。

一般的プログラマと呼ばれる人たちは

はっきり言う、ほとんどのプログラマ自称する人間の 9 割はコーダーである

言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。

そんな驚きの生体をここに晒していく。

一般的コーダー自称プログラマ)は、アプリケーションの基盤が作れない

標準化と呼ばれるプロセスで、プログラマ環境設計、組み合わせ、開発プラットフォームセットアップ、開発環境の構築手順作成、開発手順の作成必要技術考察を行う。

なぜそうなったのかは知らないが、一般的にそうなっている。

その環境に浸っているせいか、彼らはゼロベースものを作ることが出来ない。

彼らにできるのは HelloWorldコマンドプロンプトで表示するプログラム程度の事しか出来ない。

複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。

一般的コーダー自称プログラマ)は、保守性を考えない

彼らは自分に任されたものを動かせればタスクが終了する。

逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメント記載などの保守に関わることをしない。

それは彼らにとって「必要ない無駄作業」としか考えないのだ。

早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。

そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正地獄を見るという簡単論理に気づかない。

…何度味わっても気づかない。

一般的コーダー自称プログラマ)は、勉強しない。

一般的プログラマコーダー)は勉強をしない。

たとえするとしても、業務時間中に業務で使ってる技術ピンポイント学習するだけだ。

勉強会は確かに多い。「.dits」何かがいい例だ。

だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。

彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの?馬鹿か?」

あえて言おう、馬鹿は彼らだ。

一般的コーダー自称プログラマ)は、自分の使う道具がわからない

Web仕事をするならIDE統合開発環境エディタコンパイルテストデバッグ実行などを画面から行えるツール)はほとんど必須エディタで済ませる事も出来なくはない)が、彼らは状況に応じたセットアップができない。

たとえば「Mavenプロジェクト管理ツール)、checkstyleコーディング規約チェック)、editorconfig(改行、インデント文字コード設定)」が入っていたとする。

するとEclipseなどを使うとして

  1. どのプラグインを入れればいいか調べられない
  2. どうやってプロジェクトを取り込めばいいかからない
  3. プラグインを入れても設定方法がわからない(IDEデフォルト設定と、プロジェクト内の設定の違いを認識できない)
  4. IDE の設定画面がわからない

マニュアルチュートリアルを用意しないと、道具の使用もままならない。

一般的コーダー自称プログラマ)は、テストコードで書かない

テストをなるべく機械やらせようということの利点が理解できない。

コンパイルして動かして確かめればいいと本気で考えている。

そのために、何十回もコンパイルデプロイアクセスログインの手順を何度も繰り返す。

関連する他の修正を行うたびに繰り返す…。

そしてやっと動くとひと仕事終えたと満足感に浸る。

一般的コーダー自称プログラマ)は、プライドが無いか、変なプライドを持っている

ラリー・ウォールというとある有名な人物Perl開発者にしてC言語ハッカー)がいる。

彼の言う三大美徳に「傲慢」がある。

これは、自分の作るもの完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である

一般的コーダー自称プログラマ)は、このプライドはない。

彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。

同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。

変なプライドを持つコーダーは、それで運良く成功すると、自分知識は正しい、自分技術は十分なのだと考えている。

こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人環境のせいにする。

そして調べず周囲を苛立たせるのだ。

おわりに

土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない(んじゃないかと思う。)彼らは自分でなんでもやらないといけないからだ。

だが、大企業に飼われる子飼い企業派遣(そもそも人手のみを求められる企業)、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。

だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ

人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。

必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢思想はどうなんだと。

経営者マネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か?人員最適化だけを行って、生産性が伸び悩んでいないか

そのあたりは考えた方がいい。

エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase

http://futoase.hatenablog.com/entry/2016/11/19/155427



例示されている暴力はだいたい頭の悪い暴力なので反論できます


CGIには今の時代PHPを利用するのに、なぜ未だにPerlを使っているのか。処理速度も遅く、表現も難解だ。

では今あるシステム全部PHPリプレイスするとして、○人月工数必要ですがそのような予算はありません。



Go言語のもの表現力が低い。そんなものを利用するならJavaScalaで書くべきだ。ライブラリ豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。

ところでどうしてWindowsPCを開いてExcel文書作ってるのか教えてください。



Serverlessそのものサーバがなくなるわけではない。自身チューニングなど細かなリソース管理ができないPaaSを使って自身サービスの命運を預けるなんて馬鹿げている。

理屈の上ではオンプレミスIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。

みんな忙しいから結局何もやってないじゃないですか



iOSアプリのものプラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなもの技術をかけてどうするのか。

Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんものはチンケなものだ。そもそもUnityインフラエンジニアが覚えて意味があるのか。

流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか?

でも安心してください。すべてはUnity解決してくれます。そう、Unityならね。






とは言っても結局は私も暴力をふるう側の人間

例示された人たちに暴力ふるいたい。

windowsmacフロントエンドインフラ組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ!誰もお前がカバーしてない部分をサポートなんぞしねえからな!


ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ)

iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmaciphone買え(ios開発は何もかもmacxcode大前提

フロントエンドプログラマgo → goだけ使われても微妙。当然DBとの連携もあるんだよな?ん?(サーバサイドスクリプトDB連携のためにあるようなもの

サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから!(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも)

NintendoUnityインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityエディタ上で動くくらいを目標にすべきだ。

2016-11-18

JavaScriptが嫌いだ

今行ってる現場ではJavaScriptがいっぱい使われている。

使用しているライブラリjQueryをはじめ、EJS、Knockout 、jsTreeなどなどなど10近くに上る。

 

ライブラリに何ができて何ができないのかよくわからないし、

ライブラリはどうやって使えばいいのか英文サイト見ながら勉強したり、

サンプル通りに実装しているはずなのに期待通り動かなかったり……

ちなみにJavaScriptライブラリだけで1メガバイト以上のサイズがあった。

もういや。JavaScriptなんてなくなってしまえばいいんだ(´;ω;`)ウッ…

2016-11-06

なんのために必要書類なのかっていうのが重要だと思う

詳細設計つっても、実装するのに必要なのか、ライブラリとして利用するために必要なのか

どっちにしろ詳細である必要はなさそうな気もするけど

現場レベル会社が別で何度もコミュニケーションが発生するコスト

下請けに一回ドキュメントに落としてもらえばあとはまきとれるかの違いじゃないか

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