「maven」を含む日記

はてなキーワード: mavenとは

2024-04-22

■ヨーロッパの主要都市におけるソフトウェア エンジニア向けベスト カンパニ

ヨーロッパの各都市でソフトウェアエンジニアにとって最適な企業を探しているなら、以下のリストが参考になるでしょう。

Google, Facebook, Snap, NVIDIA, Microsoft, Apple, Oracle, Snyk, GetYourGuide, UBS, Swisscom, DFINITY, Cisco.

Google, Facebook, Snap, Jane Street, Stripe, Coinbase, Apple, Amazon, Hudson River Trading, Citadel, ByteDance, Two Sigma, Palantir, Bloomberg, Revolut, GSA Capital, Marshall Wace, Quadrature, Five Rings, G-Research, Starling, Personio, DeepMind, DRW, Millenium, BlackRock, MAN Group, Jump Trading, DE Shaw, AQR, Maven Securities, Point72, IMC, Optiver, Susquehanna (SIG), XTX, Old Mission, Squarepoint, Qube Research & Technologies (QRT), Yelp.

## アムステルダム, オランダ

Uber, Databricks, Bitvavo, Booking, Miro, Flexport, Atlassian, Spotify, Optiver, IMC, Amazon, Adyen, Google, Stripe, Flow Traders, MessageBird, Reddit, Box, JetBrains, Personio, Elastic, GitHub, Catawiki, Tower Research, Radix Trading, Headlands Technologies, Tomtom.

## パリ, フランス

Google, Meta, Datadog, Criteo, Microsoft, Stripe, Airbnb, Amazon, Atlassian, Hubspot, Workday, Ankorstore, Red Hat, Algolia, Alan, 360Learning, ContentSquare.

## ベルリン, ドイツ

AWS, Amazon, Microsoft, Wayfair, Google, Meta, Apple, HubSpot, Stripe, NVIDIA, Snowflake, Personio, Databricks, JetBrains.

## ダブリン, アイルランド

AWS, Microsoft, Google, Mastercard, Workday, Salesforce, Meta, Stripe, VMware, LinkedIn, Etsy, Personio, ByteDance, Coinbase, Hubspot.

## ミュンヘン, ドイツ

Google, Apple, Microsoft, Nvidia, Adobe, Workday, Celonis, BMW, Salesforce, SIXT, SAP, Huawei, Personio, Intel, JetBrains, IBM.

## ワルシャワ, ポーランド

Google, Snowflake, Netflix, Pinterest, Rippling, Oracle, Waymo, AMD, Samsung, NVIDIA, Box, Warner Bros, Visa, Amazon.

## バルセロナ, スペイン

Amazon, Apple, New Relic, Stripe, Rippling, Revolut, Skyscanner, Microsoft, N26, Criteo, Adobe, Thoughtworks, Oracle, Glovo, Personio.

## ケンブリッジ, イングランド

Apple, Amazon, Roku, Arm, Microsoft, Qualcomm, MathWorks, AMD.

## エディンバラ, スコットランド

Amazon, Oracle, Microsoft, Flutter, Unity, Skyscanner, Huawei.

## ベオグラード, セルビア

Databricks, Microsoft, Nutanix, Rivian, Foursquare, Yandex, JetBrains, Nordeus, Luxoft.

## マドリード, スペイン

Amazon, Datadog, Microsoft, Apple, Google, Personio, Twilio, Glovo, VMware, Meta, Oracle, Revolut.

## ストックホルム, スウェーデン

Klarna, Spotify, Netlight, PayPal, Ericsson, Ubisoft, Warner Bros, King, Google, Oracle, AWS, Microsoft, Wolt.

## クラクフ, ポーランド

Google, Rippling, Oracle, Revolut, Uber, Amazon, Deliveroo, IBM, Splunk.

## ブカレスト, ルーマニア

Crowdstrike, UI Path, Google, Adobe, Stripe, Microsoft, Oracle, IBM, Amazon, Electronic Arts (EA).

## コペンハーゲン, デンマーク

Microsoft, Maersk, Zendesk, Workday, Unity.

## プラハ, チェコ共和国

Productboard, Pure Storage, Apple, Workday, Oracle, Microsoft, JetBrains, Proton, Parrot.

## タリン, エストニア

Bolt, Wise, Microsoft, Twilio, Wolt.

## オスロ, ノルウェー

Microsoft, Cisco, Aker Solutions, Arm, Mastercard, Meta, Kahoot, Autostore, Remarkable, Netlight.

## ソフィア, ブルガリア

VMWare, Uber, Docker, IBM.

これらの都市は、ソフトウェアエンジニアにとって多くの機会を提供しています。それぞれの都市が提供する企業は、エンジニアが自身のキャリアを発展させるための多くの選択肢を提供しています。それぞれの企業が提供する機会や文化は、エンジニアが自身のキャリア目標に合わせて最適な選択をするのに役立ちます。 [

Permalink | 記事への反応(0) | 05:20

2023-09-06

■anond:20230906181008

その点Javaは15年以上mavenのままだし、それ以前のantもまだ使える

話の分かるやつだ

Permalink | 記事への反応(1) | 18:14

2023-01-12

■anond:20230112221133

・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない

これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。

かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。

フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。

ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。

派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。

ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。

アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。

全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。

使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer 出身でコード書いてたなら当然できるよね、というレベル。

今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。

分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。

JavaならSpringboot+gradle +JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。

インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。

AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。

ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。

LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。

dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。

構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。

常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。

トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。

サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。

CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。

CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。

どうだろう、かなり雑に書いたが雰囲気は伝わると思う。

あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。

Permalink | 記事への反応(1) | 23:33

2022-04-07

■れ: node.js の呪い

https://d.potato4d.me/entry/20220405-nodejs/

が話題になっているけど、本来人類に必要なのはクロスプラットフォームな実行環境であってNodeじゃない。

TSが流行ったのはJSがクソだから。BabelしなきゃいけないのもJSにトランスパイルしなきゃいけないからであって、必要なのは JVMやCLRのような言語実行環境。

Reactが流行ったのはshadow domだけど、必要なのは DOMじゃなくてちゃんとした「アプリ」開発用のイベントモデルとレイアウトマネージャ含むGUI 環境。

フロント界隈の流行廃りって本質的な改善ってよりもほかの良い技術をいかにブラウザ/Electron等JS エンジンという限られた環境に持ち込んで幸せになるかがメインに見えるので地獄に見える。

「アプリ」書くのになんでドキュメント記述用のHTMLに今ものっかってんだよと。

MavenやらGemsができて依存管理楽になったとか、RailsがでたときのようなCoC良いねとか開発の考え方を変えるフレームワーク、　rspec/Cucumberがでてテスト最高とか、c10kも怖くない非同期I/Oとか、好きな言語が使えるJVM/CLRそもサーバーならrustでもgoでも好きなものが動くとかとか本来の開発を楽にするという意味のブレークスルーってあんまりみられない気がしている。なんでフロント界隈の新技術ってあんまりわくわくしない。

逆にちゃんとしたクロスプラットフォーム実行環境がブラウザしかないということなんだけど、ブラウザなかなか進化しないし RIA は Apple 様が切り捨てるからなぁ。

ということですべてはブラウザが悪い。JavaScript 以外がちゃんと動くクロスプラットフォームのGUI 環境が必要。でもプリインでモバイルでも動いてOS から独立して協調して作られていて、Webという既存の大量の資源にアクセスしやすいものは現時点で実質ブラウザ一択。つまりWASM に期待。次にHTML であるべき文書はともかくSPAなんてもう「アプリ」なんだから HTML 手書き文化もうやめてネイティブアプリ並みの GUI 作成環境も復権しよう。

するとクライアントでも好きな言語が使える。そして同じ言語がいいとサーバサイドで Node.js を使う必要もなくなりへっぽこプログラマが Node のイベントモデルを理解せずに使うこともなくなる。

そしてそれらができたときに Node というか JS/HTML の呪いから解放され人類に平和が訪れるのだ。君はその後も Node.js を使っても良いし使わなくてもいい。

ま、私はそんなもの作れないのでありものでがんばりますがね。

Permalink | 記事への反応(0) | 01:39

2021-06-12

■今までの尽力に対する感謝と、君への今後のアドバイス。

https://anond.hatelabo.jp/20210610184501

文面からおそらく弊社の、しかも関わりのある事業部なのだろうと想像した。そういう意味ではまずは今までご苦労様。

その上で一言アドバイスさせてくれ。

自己紹介

まず自己紹介からしよう。私は主に公共向けのSEをしている部長相当職（社内ではある固有名詞で呼ばれている）だ。社内の製品は一通り把握している自負はあるので、よっぽどマイナーなものでなければおそらく君のところの製品も触ったのではないだろうか。

社内の開発環境について

開発に必要があるなら申請を出せば普通に入手できるし、Gitも普通に使っている。正直なことを言おう。そんな小さいことで辞めたのか？と思ってしまった。35歳で主任（これもある固有名詞で呼ばれてたんじゃないか？）ということはそもそも開発者なんてフェーズはとっくに過ぎてマネージメントを任される頃のはず。これはたとえ製品開発の事業部だったとしてもそんなに変わらない。それなのにその視座の低さがとても気になったよ。概して若いコーダーは顧客のメリットが0であるような単なる自己満足としてGithubの利用やDockerを使いたがるが、悪いけどそのまま大人になってしまった感じを受けた。開発環境の優劣というのはそんな低レベルな話ではなく、上流工程での品質の作り込みがしっかり行われているかとか、品質管理のKPIがしっかりされており、そのKPIに対するPDCAが回っているかとか、人月単価を適正に管理し競争力のある製品を作る予算管理ができているかといったことのほうがよっぽど重要。

年収について

弊社はあくまでも「ものづくり」「エンジニアリング」の会社であって、「コーダー」の会社ではない。そのためDockerだのGithubだのMavenだのといった要素技術に対してそんなに価値を認めてないんだよね。もちろんそういった技術で儲けようとしているWeb系の企業がたくさんあるけれど、年収を比べてみれば結局どっちの市場評価が高いのか、よくわかるんじゃないかな。「ものづくり」で大事なのはあくまでも顧客の要求を満たすことで、それはDockerだのGithubだのMavenだのを使うことととは次元の違う話だし、市場価値が高いところにコミットしてそうでないところを適正に管理しているからこそその年収が出せるものだと思ったほうがいい。今の年収と同じ水準でモダン笑な環境に転職したじゃないかと反論されそうだが、転職市場は前職の年収ベースになるので結局君の実力ではなく弊社の実力が評価されただけなんだよね。そこは謙虚になったほうがいいと思う。

君の失ったものと見えてないないもの

まずシステム開発は「ものづくり」ということが見えていない。「ものづくり」というのは単にコードを書くというだけでない（君はそこにフォーカスしすぎて、その環境の悪さだけが目についたように見えた）。市場の要求に対して適切に答えてるのが命題であり、技術は単なる手段ということを忘れてはいけない。プログラミングというのは手段である技術のたった一要素に過ぎない。そういう徹底的な顧客志向を日本のメーカーは長いことやってきており、高い生産性を実現してきたし、社員にもその精神を学んでほしいという一心でビジネスを動かしている。だが、最近のIT系企業は「ものづくり」ではなく技術を目的にしているところが多いよね。MacやGithubとか言ってる層は特にその気が強いと思うのだが、君は結局そこに行ってしまったようだ。

これからの行動の指針のアドバイス

以上を踏まえておじさんから一つだけアドバイス。今のWeb系がやっていることは所詮大昔の技術を再発明しているだけであり、本質的に価値が薄いということ自覚した上で本当に顧客が欲しい物を作るということを忘れないでほしい。例えばDockerなんて大昔から Linuxが持っている機能の寄せ集めだし、Gihubなんて本質的にはファイル名に日付を管理するのと変わらない。弊社に関して言うと、AWSなんていってるけど所詮 VMだし、弊社はハードウェアレベルでより高い技術を持っている。AI 企業は専用AIを個別案件ごとに作っているが、弊社は汎用AIを世界で初めて開発した。でもそれらを積極的に宣伝はしていない。なぜか？それらは単なる手段だから。むしろお客様へのソリューションという形で宣伝していて、結局顧客のビジネスにフォーカスしているんだよね。だからこそ利益が出せ、年収も高いというわけ。なので、再度いうが、本当に顧客が欲しい物を作るということを忘れないでほしい。

Permalink | 記事への反応(6) | 03:15

2021-06-10

■日本の古き良きIT 企業を退職して3年がたった

3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。

客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、

会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。

これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。

Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、

手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに

ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、

Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上流設計、

一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。

色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる

今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェアは

研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRuby しか書いたことがない文系新卒の子が出てきた。

一応研究所の人だし…と思って新バージョンのプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。

研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。

また前の会社独特の文化として、大きなバグを出した開発者の反省会（社内ではとある固有名詞で呼ばれている）があった。

この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。

このとき、担当の品質保証部は「連帯責任だから」という理由で資料レビューに大変な精を出す。余計なお世話だ。

このため10〜20ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである。

連帯責任とかいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。

幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。

こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。

そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト」

「GitHub」「CI/CD」という発言がポンポン出てくる。メルカリだのGoogleだのといったイケイケWeb系ではなく、

いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで

イケイケWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署に転職した。

そしたら何だこれは。最高スペックのMacBook Pro から GitHubにpushするだけで自動デプロイで即サービスイン、

問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスでログをチェック、即修正即デプロイ。

社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署が対応に走る。Office ツールはGoogle Docsで、

計算表はちゃんと表として使っている。開発者はちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく

純粋にエンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、

年収は30万ほど増えて大台に乗った。

さて、それから3年がたった。人間というのはいい環境になれると対して喜びを感じなくなる、というのはそうだと思う。

今では別にdeployブランチにマージされたらCIが走って自動でテストが走りデプロイされるのも、だから何？

って感じだしまぁ普通の仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし

（例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど）などもある。

ただ一つ言えることは前の会社には戻れないな…ということである。人間一度生活レベルを上げてしまうと下げるのは

とても苦痛に感じてしまうものである。

ただ、一つだけ今の会社に転職してよかったと感じ続けられることが一つある。それは人だ。

前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。

芸能人とゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。

でも今の会社では雑談としてFastlyが落ちても大丈夫なCDN構想とか、AtCoderの話をして盛り上がることができる。

ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。

追記

皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます。

真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの？どういうモチベーション？？

製品自体が90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります。

またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。

そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、

もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能が必要になります。

こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。

clearcaseよりもsubversionの方が100億倍導入も運用も簡単だと思うんだけど品管どうなってんの？

ClearCaseご存知な方がいるんですね！一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の

社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。

例えばお客さんから「この機能がバグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、

コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています。

そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識のアップデートが

必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。

ただ、社内の生産性を向上させるのが目的の部署としてはSubversionやGitを社内に浸透させたがっているのも事実で、

新規プロダクトなんかはGitを使っていました。ただしGitHubはプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止

になっているので、相当の理由がない限り使えないかと思います。

主任クラスでも1000万円近くもらえるのか。すごい。

1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというものが存在して管理職を除く最上位のランクに

なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、

研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。

平均では30代中盤ぐらいでしょうか。

ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。

ボーナスは個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価の場合は夏冬とも150万以上でした。

最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う

なるほど、たしかに。ちょっと言葉の選びが悪かったかもしれないですね。

Permalink | 記事への反応(20) | 18:45

2018-11-30

■今の子、IT開発のハードル高すぎない？

入り口がスマホだったりするわけじゃない？

swift playgroundとかswiftが知ってる人フレンドリーではあるけど、初心者には分かる仕組みになってるのだろうか？

SI 業界に入った子がSQL書けとか、ES6書けみたいなこと言われたってハードル高すぎないかねぇ。

AWSとかアラフォーの俺も全然分からない。awscliでスナップショットとれるなんて今日初めて知ったよ。

今のプラグラミング言語って色んな言語を取り込んで高機能化してる訳じゃない？なんでそんなことしてるのか分かんないと思うのね。

伝わる人に言うと、Java だってAutoBoxingが前提だったりするわけじゃん？42+"円"とか書いちゃう訳よ。コンパイルエラーにならないのも頑張りすぎだろと思うけど。

あとmaven使えば色んなライブラリ使えるわけじゃん？今ならGradleなのかい？よくわかんねぇけど。俺はよく分かんないけど、使いこなせてるのかね？

AWSもES2の説明はできてもS3の説明できる先輩がどれほどいるか。ストレージや仮想化の知識が前提にない人は説明はキツいなと。AIMとか混ざると地獄よね。

プログラミングに戻ると、今どきの言語って最先端で書かれると記号や謎予約語が多かったりするんだけど諸先輩方は大丈夫かなと。

っていうか、ラムダ式とかもSI 業界とかだとキツいよねと思うのだ。全然最新の技術じゃないのにね

Permalink | 記事への反応(3) | 23:11

2017-09-17

■まべーん

repo1.maven.orgのリポジトリインデックスデータを取り込みたいからアップデートボタンを押してねと言われ幾星霜

このインデックスデータとやらは何十MBあるんだ

追記：

あった

nexus-maven-repository-index.gz                   2017-09-10 15:25 397699470

いちじゅうひゃくせん…、400MBか。この回線じゃ無理だな。ごはんでも食べよう

Permalink | 記事への反応(0) | 17:55

2017-02-26

■自動化って

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

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

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

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

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

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

Permalink | 記事への反応(0) | 07:50

2017-02-01

■ホワイトリスト 形式のプロキシ建てるのやめてほしい

某大手 SE 会社で作業することになったけどさあ・・・

mavenもnpmもpipもgemもdocker hub もつながらないような環境で開発しろとか言われてもムリだよ

CentOSの公式リポジトリだけ開けてれば問題ないとか思ってんじゃねーぞ

プロキシ建てるのはいいけど、リストメンテする気がないなら、せめてブラックリスト形式にしてくれよ。仕事できないよ

Permalink | 記事への反応(1) | 21:19

2016-11-20

■大多数のプログラマは…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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

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

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

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

Permalink | 記事への反応(0) | 19:27

2015-02-11

■SpringBootアプリをjavafxを使って配布しやすくしよう

概要

Javaで開発されたアプリケーションにはインストールにまつわる難点がある。

それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。

また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。

javafxで導入されたパッケージャを用いることで各OS ネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。

SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。

問題点の整理

Javaで開発されたアプリケーションの配布には以下の問題点がある。

jreのインストールが必要
- 30億のデバイスで動こうがそれはjreをインストールした後の話。
- .netのランタイムのインストールすら面倒で敬遠されるのにOracleとか無理やろ。
- 自動インストールさせるのも面倒。野良リポジトリ URLを追加したりOracle からのダウンロード自動化したり。
起動の仕方があまり標準的でない
- 一般人にとってアプリケーションの起動とは application.exe や application を実行するもの。
- application.bat や application.sh とかいい加減にしろ！
- java -jar application.jar とか本当にユーザーに起動させる気あんのか！
プロセス名がすべてjava
- 負荷監視時のプロセスの特定が面倒
- 運用時、killする対象のプロセス取り違えなどのリスクがある
- だから java という文字列をユーザーに見せるな！！
複数バージョンのjreをアプリ毎に切り替えないといけない場合は更に煩雑に
- JAVA_HOMEを書き換える？alternatives --config java？
- そんな複雑なことできるか！馬鹿にすんな！！
パッケージングに関する情報や知見に乏しい
- ドキュメントは英語だったり曖昧だったりで開発者の意欲を削ぐ。
- java web start とかコード署名とか、本当にもうお疲れ様です。意味わからん。
インストーラーじゃない
- application.tar.gz とか application .zip とか
- まぁ個人的にはこっちのほうが好きだけど

解決方法として

javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。

javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。

Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。

公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。

実際にどのようにすればパッケージングできるか

まずアプリケーションを maven アプリとして開発する。

pom.xml に以下を追加する。

mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。

vendor は適当に組織や個人の名前を入れておきましょう。

※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805

&lt;plugin&gt;
  &lt;groupId&gt;com.zenjava&lt;/groupId&gt;
  &lt;artifactId&gt;javafx-maven-plugin&lt;/artifactId&gt;
  &lt;version&gt;8.1.2&lt;/version&gt;
  &lt;configuration&gt;
    &lt;mainClass&gt;[main method class]&lt;/mainClass&gt;
    &lt;vendor&gt;[Vendor Name]&lt;/vendor&gt;
  &lt;/configuration&gt;
&lt;/plugin&gt;

あとはそのままビルドすればよい。

maven clean jfx:native

ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。

本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。

これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。

/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。

app の下にはビルドした jar ファイルや依存ライブラリが置かれています。

runtime の下には実行用の jre が配備されています。

実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です）

課題

インストーラーで含めることのできる実行環境は jre なので jdk が必要とされるアプリは実行できない
- 問題になるのは jsp 。jsp のコンパイルに javac が必要なので。
- 切り捨てるのが一番だとは思いますが。
サーバー系のアプリの場合は init script を用意しなければいけない
- 今後の検討課題ですね。