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

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

2017-01-16

言語ソフトライブラリ選択の時に「別に新しいのを追わなくていい」と言う人間

フリーランスの1人で作業が完結してるつもりの人間が多くて全く当てにならない。

adobeとか言ってる人間も結局広告代理店印刷所と仕事してないからそういう発言になってる。

自分以外の人間作業する可能性がある、

とは考えていないので

ソースデータメンテしにくい状態になっていたりしてうんざりする。

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

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

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

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

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

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

2016-11-01

業務系にWebアプリケーションが人気である理由がわからない

特に最近JavaScriptごりごり使ってるやつとか

一昔前なら軽量とか工数が少なく済むとか理由があったんだろうけど

今はJavaScriptごりごりでRichどころかFatになってるじゃん

マシンスペックも上がってるんだからもうクライアントサイドもサーバサイドもJavaでいいじゃん

 

JavaScriptただでさえ読みにくいのにライブラリが大量に使われててもうわけわからん

JavaScript使いたくないよ~( ノД`)シクシク…

2016-10-23

http://anond.hatelabo.jp/20161023044837

NVIDIAと組んだことが裏目に出る気がして仕方がないのだがどうだろうか。

NVIDIAGPUでは唯一の成功者になっていてGPGPUDeep Learningだと元気がいいが、

モバイルでの施策は悉く潰えている。

Android 3.x HoneycombはNVIDIAが driverを公開しないためにAOSPの黒歴史扱いでなかったことになっているし、

SHIELD TABLETは全機回収騒ぎを起こした。

TEGRA K1はすぐに後継のTEGRA X1が出てSDKが禄に更新されなくなり、

TEGRA X1車載メインだが自動運転などさせようと思ったら非力だ。

OSライブラリなどソフトウェアを全部任天堂部隊担当して

アプリケーションを作りやすい開発環境を用意できても、

NVIDIAハードウェア陳腐化するのが早すぎる。

2016-10-17

http://anond.hatelabo.jp/20161016224105

わかる。

俺はWebプログラマだけど、プログラミング界隈なんて、超絶優秀な人が馬鹿みたいに働く世界からな。(別に仕事のものではないが、自分仕事で使うためのツール/ライブラリだったりとかね)

家族かいても、なんか面白いこと見つけたら深夜まで調べたり実装しちゃったりする。

確かに、年齢による体力の衰えについては、今定年を迎えたWebプログラマっていうのは存在しないわけで、今後どうなっていくのかは気になるところだ。

2016-10-13

主語デカ系】ITに対する教育コストが高くなりすぎている

なんか「プログラミングはそんな簡単じゃない」みたいな話題があったじゃないですか。

なんかうまく言えないんだけど、プログラミングに限らず、今の世の中は若者ITスキルを得るのにかかるコストデカくなりすぎてないですか?

俺ら40絡まりのオッサンどもはマイコンパソコン黎明期あたりから趣味としてITに触れていて、

できることも限られていたから、その辺のパソコン少年的凡人だってH/W S/Wの根本から触れてた人が多いと思う

でもって元々大したことができなくっても、動くだけで楽しかったしね

それが今では、フロントエンドアプリを作るってならリッチ統合環境とかライブラリが揃ってて、

別にH/Wのハの字も知らないでも結構見栄えするすごいものが作れちゃったりするわけじゃないですか

日常生活だってものすごい能力をもったものが当たり前のように手のひらに収まってる

こんな環境では、よっぽど高い意識能力を持った奴でないと、H/Wの基礎からそれを動かすS/Wをキッチリ学ぼうなんて思わないでしょ

手のひらですんごいものが動いてるのに、Hello world!やったって面白くもなんともないよね

よしんば興味をもったところで、今度は突然40年前に逆戻りだ

しかも目の前で起こっている出来事からイメージリンクしにくいから凡人には理解し辛い

オッサンどもはテクノロジの進化とともに自分たちも年を重ねてるから、頭が凡人でもなんとかかんとか「流れ」で理解していけるし、理解するための時間たっぷりあった

から別にそれほど高い意識とか能力が無くても、ちょっとしたゲーム好きから始まった奴とかでもそれなりに基礎を体で理解していて、みっちり鍛えられてはいないけど

全方位まぁまぁ戦える在野の武士っぽい奴らがいて、そいつらがこれまでのITをそこそこ支えてきたように思う

ところが今の若い連中は下手すりゃそれを数年で詰め込まなきゃいけないし、とっかかりが現実とロングディスタンから明確な目標とか意思がないとモチベが保てない

そりゃフロントエンドアプリはいいかもだけど、ITを支えるのはそこだけじゃなくて、今だってH/Wからすべて理解したうえでの領域人材はたくさん必要な筈

どっこい、昔は沢山いたはずのソコソコかもしれないけどまぁ戦える在野の武士絶滅寸前で、武士といえば兵法も知らない農民バイトか、

逆に超一握りの生粋武将だけになっちまったような気がしてるんだが、これからITはそれでやっていけるんかいね?

教えて!エロい人!

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