「バックエンド」を含む日記 RSS

はてなキーワード: バックエンドとは

2022-05-30

anond:20220530094051

説明しよう】

Reactは初心者には難しい言語

ちゃんと開発やろうとしたらバックエンドフロントエンド知識がいる。

でもちゃん勉強したら、バックエンドエンジニアがいなくても開発できるようになる。

ということで職を失いそうなバックエンドエンジニアから逆恨みされている。

2022-05-29

anond:20220529225103

JSしかないわ。どんな立場でも知っておかなきゃいけない、受験で言う英語みたいな感じだわ。

バックエンドやらTSやらフレームワークやらとかいい出すとキリがない。

JSやっとけ。損することはない。ただあまり厳密さに深入りしたり、過去の書き方を深く学ぶ必要はない("var"について、とか)。

anond:20220529085043

早いうちからTypeScriptを使いこなしてる人って

java経験者だと思うからバックエンドフロントエンドの垣根って消えてる気がする。

最近フロントエンドフレームワークバックエンド言語知識(開発現場で使うような色々)がない人が学習するのキツくね?

ってのが多い印象。これどうやって初心者勉強すんの?

意外とできるのか?って思ってるけど真実は闇の中…。

2022-05-14

anond:20220514092425

やっぱそうなのかな

なんか調べたらフロントエンドはある程度鉄板がでてくるんだけど

バックエンドはこれっていう定番がなくて慣れてるからRails使い続けますみたいな話もよく出てくる

もうよくわからん

Railsが死んだのはわかった。では何使えばいい?

現代Webアプリケーションフロントエンドが中心で

バックエンドJSON返すだけの存在になったのはわかった。

からRailsやLaravelみたいなフルスタックフレームワークが捨てられてるのもわかった。

では何使えばいいのかよくわからん

Firebase? AWS Lambda?

Go流行ってるらしいけどGoEchoってやつを使えばいいのか?

2022-05-12

anond:20220512114452

フロントエンドの使いづらい言語が、10年ぐらい前から徐々に使いやすくなって、じゃバックエンドも同じプログラムで書けたら楽だよねってことで、バックエンドでも使われるようになったわけよ。

 

2022-05-08

anond:20220508155026

1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者マジで底辺しか漂流できないので覚えたほうが良いぞ。

それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。

そうは言ってもリソース管理めちゃくちゃ頑張らなきゃいけない仕事が無いんじゃ・・・

しろどういうシチュエーションリソース管理しなきゃいけないのかすらわからんのじゃよ・・・

ギークためのChromebook入門

エントリ目的

ライトコンピュータユーザ一切合切無視してギークギークのため情報共有するためのエントリ
感想はてブへ、質問トラバに投げれば誰かが答えるんじゃないか?(他力本願)

開発者は初手でデベロッパーモードにするべし

セキュリティ懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
用途中でデベロッパーモードにするとストレージファクトリリセットされるので注意。

ハードウェア選択

Webで完結するのであれば低性能機で問題ない

Webエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的タブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ

ただし、Webベースゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。

ChromeOSハードウェアスペックで殴ると快適なのは変わらない

Core i7クラスCPUや16GB以上のワーキングメモリSSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラス3DCGAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。

Android Appレイヤーを中心に運用したいと考えてるならばx86_64機は非効率

Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。

1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者マジで底辺しか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。

しっかりリソース管理できているChromebook向けビルドアーキテクチャによらずサクサクなのでクロスプラットフォームビルドマジで開発チームの腕が如実に反映される。

ちなみにSnapdragon 8 Gen1なChromebook公式発表は今のとこ無いのでAndroid Appレイヤーブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。

Android Appレイヤー

macOSiOSレイヤーよりAndroid App数は多いし操作性は良い

Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。

Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。

GPS事実上ほぼ機能しない

ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバ接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。

USB over MIDIが使える

Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能ものの、iOS比較してレイテンシがそこそこ大きくDTM活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。

そもそも既存Android AppなDAWVSTやLV2などの外部プラグイン対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか?
ただし、DAW単体でDTMを完結するとレイテンシほとんど気にならなくなるので絶対Android AppでDTM不可能というわけでもない。

Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。

ChromeOS向けマルチタスク対応していないとAndroid Appはスリープする

ChromeOS向けマルチタスク対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。

まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの?とは思う。

ICT教育日本中学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスク考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか

Linuxレイヤー

実体LXC/LXD

LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも?

デフォルトイメージはChromeOS向けにカスタムされたDebian
別のLinuxディストリビューションへ置き換えることも出来るが一部機能制限される可能性がある。

IMLinuxレイヤー側で用意する必要がある

ChromeOS動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊ものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難

USB Pass Throughが使えない

ChromeOSマウントされたUSB機器、というかシリアル接続された機器Linuxレイヤーから認識しない。
見掛け上で接続されているハードのすべてはソフト仮想接続されているだけなので、一部経路から上手く認識しなかったりする。

まりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーゲームやろうと思ってもUSBゲームパッド動かないのでマウスキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。

それぞれが独立しているLinuxレイヤーAndroid Appレイヤー相互認識しない

言うなればAndroid Appレイヤースクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリキャプチャしようと思ってもキャプチャできず撮像は暗転している。

ChromeOSホストLinuxレイヤーAndroid Appレイヤーゲストなのでそりゃそうなんだけど気付かないとハマる。

LinuxレイヤーDockerを構築するのはやめておけ

LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境Chromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
まりゲストOS制限KVMも引き継ぐ。

ただしこれはDockerが導入できないという意味ではない。
自分解決する気概があるのならばDockerは便利に使える。

Web開発であれば必要十分

CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。

GIMPInkscapeなども動くけれどデザイナーAdobe使いたいんじゃなかろうか?

Chrome OS向けAndroid Studioが存在する

Android App向けIDEAndroid StudioはChromeOSけが存在するのでAndorid App開発が可能
しかデベロッパーモードでなければエミュレータや実機デバック制限が発生するので注意。

3DCGゲームを作りたいのであればGodot

UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスMITなので商用利用だってイケる。

3Dのほか2Dゲームもいける上に、最近IDEよろしくマウスポチポチUIを作れるし、軽量動作物理演算日本語ドキュメントまで揃っているので中高生ガンガン使える素晴らしいIDEだ。

総評

浅い部分は気軽だが深い部分は非常に難解、それがChromebook

浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザ視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。

しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇Linuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。

そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。

ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ

追記

少なくともGoogleエコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースアップデート無償で得られ、Gentoo LinuxベースなChromeOS潜在的マルウェア絶対数がそもそもWindowsMacよりも少ないという利点がある。
Bluetoothイヤホンヘッドフォンヘッドセットも使えるし、NestスピーカーNest HubNest Camを持っているのであればGoogleアシスタントからコントロールが容易なのは想像が付くだろう。Android AppレイヤーGoogleホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い
もちろんこれは選択するハードによるもの指紋認証ロックを解除することまでできる。

Googleエコシステムへ浸かっていてGoogle個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言欠点表現することが可能だ。


Chromebookじゃなくても別に良くね?」


そう、ギークLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギーク別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OS別になんだって良い。
このエントリは単にChromebookという新しい沼ギークの皆さんをご案内しているに過ぎないのだ。

2022-04-29

anond:20220429094749

両方やってもいいし、やらなくても大丈夫

というのは「エンジニアになる」という目的だったら、その二つをやらなくても達成できるから

自分場合情報処理は持ってないし、サービスを作った訳でもなかった。

まったくの未経験だったから、公式チュートリアル適当勉強してとりあえず入れそうなSES企業に入って、業務経験を積んだ。

それで今、受託会社転職してフルリモートフレックスで楽しく働けてるよ。

もちろん、エンジニアとしては両方やった方がいいのは事実。学ぶ事は大事だし、少なくとも何にもやってない人よりは書類審査も通りやすいし。

でも「何のためにその勉強をするのか」を明確にしないと、モチベーションも続かないし上手くいかないと思う。

最初から自社開発のイケてる会社で働きたいとかなら、サービス作って自分でもやれる所をアピールするのが良いし

固めの会社なら基本情報処理価値をそこそこ考慮してくれるだろうから、「何のためにやるか」っていうのを自分に問いかけるといいよ。

あと「エンジニアになる」っていう漠然目的解像度を上げると良いかも。

例えば、要件定義から実装まで全て行えるエンジニアになるとか、バックエンドのこの言語を極めたいとか。

まあ別に何でもいいんだけど、多分それをやっておくと採用面接でも役に立つし目的にも近づけるよ。

2022-04-22

軽々に消費税を動かしてほしくない

ECサイト消費税変更で、それなりに面倒だったんだ。たかだか景気対策程度のために消費税を軽くするとか、止めてほしい。もし期間限定なら、なおのこと。

ECサイトですらコレなんだから、このバックエンド倉庫とか実店舗販売とか)を支えている側なんて、さらに大変だったろうに。

2022-04-19

バックエンドエンジニアおすすめ転職サイト教えてくれ

今の会社特に不満は無いんだけど、給料が上がらないので転職を考えはじめた。

試しに「バックエンドエンジニア 求人」で検索かけてみたら、求人サイト死ぬほどヒットしてどれ使ったら良いかからない。

1個1個ぽちぽち登録しながら転職活動やっていくしかないのか?

俺が知らないだけで実はなにかベストプラクティスがあるんじゃないか

2022-04-10

そもそもITの優秀な人はゲーム作るよね

からゲーム作ってるのは頭おかしレベルの凄い人達だよね。

マリオ作った人とかDQ音楽作った人とかソニック作った人とかFF3のアレやった人とか。

最近でもUE5は凄すぎるし、ソシャゲだってバックエンド構造・開発体制は凄く良く出来てて感動する。

アジャイル開発すら導入できないアホ企業は1bitでいいから見習って欲しい。

おまけにいろんなアイデアとか斬新な発想ってゲームからまれてきてると思ってる。

ぶっちゃけiPhoneNintendo DSパクリだと思ってるし、SNS前身ネット掲示板の発展にはセガBBSが大いなる役割を担ったと思ってる。

昔は軍事技術の民生品でいろんなものが作られてたけれど、今はゲーム業界から引っ張ってきてるものが多いと思う。

多分そのうちスマホにPS5のハプティクスが付くと思う。

そんな感じだから優秀なエンジニアソシャゲ作ってても全然不思議じゃ無い。

ていうかソシャゲ作ってて何が悪いのかさっぱりわからない。

ゲームしてみんな楽しくて幸福だろ?今でいうとウェルビーイングか?

健康に関与しないと「有益」って判断してくれないの?

クソみたいなお仲間集団で作り上げられたコミュニティで「論文」を書いてないと有益じゃないの?

エンタメ業界だけじゃなくて、美味しい料理提供すら「娯楽」扱いするんですかね。

ソシャゲ作ってて何が悪いのかわからんし、何が不幸なのかもさっぱり分からんな。

2022-04-07

https://cloud.google.com/blog/ja/topics/customers/kurasushi-gke-edge-tpu

くら寿司:GKE や Edge TPU などを駆使して来店から会計までを完全自動化し、新しい生活様式のためのサービス提供

そんなもんバックエンドが何で動いてようが関係ねーだろ感ある

2022-03-30

anond:20220330153643

そう思う

エンジニアたる我はバックエンドSQLだけ書いて余生を過ごしたい

FireBaseとか出てきてバックエンドのもの不要とか言われ始めてるけど

2022-03-14

すぐ復旧するのすごいな

テキストベースで軽量なサイトとはいえバックエンドDB接続は膨大だろうにすぐ復旧するのすごいな。

AWSとかのPaaSでやってるのか、VMレベルで可用性してるのか。

ニコ生とかもここ数年は2時間以内には復旧してるね。

2022-03-13

ヤフー株式会社退職しました

新卒入社して約4年務めたヤフー株式会社退職しました。

ヤフーショッピング周りでバックエンド開発運用に携わっていました。

退職理由はいくつかありました。

低い給料

ヤフー給料IT業界でも低いことで有名です。

https://opensalary.jp/companies

このサイト結構優秀で、他の企業に在籍している知り合いの話を聞いている限りでは、概ね現実と近い分布になっていると思っています

ヤフーを見ると、2022年3月現在での平均年収は650万円ほどになっており、名の知れたIT企業群と比較しても給与水準が低いことが分かります

有価証券報告書を参考にした平均年収を紹介しているサイトもありますが、そこだとヤフー年収2018年までは750万円、2019年からは1000万円ほどになっています。これはヤフーがZホールディングスという持ち株会社に移行したためで、経営陣が多いZホールディングス有価証券報告書の平均年収が高くなってしまっています。残念ながら、現状は上のサイトくらいの年収レンジです。持ち株会社したことで、見かけ上の平均年収が上がったわけですが、こういうセコイ対外アピールをするような会社ってことです。

経営陣は、ヤフー世界リードするテック企業特にAI分野に力を入れていく!などと株主総会などで豪語していますが、世界トップIT企業給与水準比較しても半分以下です。給与が低く、特に若手で優秀なエンジニアがどんどん抜けてしまうことが現場レベル社員で常に課題として感じられていました。

そういった話がずーーーーっと出ているんですが、全く改善の話が出てきません。経営陣は何を考えているんですかね。

ごくまれ待遇について変更がなされるのですが、

https://www.itmedia.co.jp/news/articles/2201/12/news105.html

例えばこんな感じで的外れな感じなってしまっているのが現状です。

ニュース見出しには「LINEメルカリに対抗!」などと書いてありますよね。

「いや、あんたたち世界で戦える企業にするんじゃなかったの?なんで日本企業と比べてるの??しかLINEって同グループだよね??」と思った記憶があります。まあ国内同業種に比べても肝心の給料が対抗できてませんしどうでもいいのですが。。

大企業にしては将来を楽観できるほどの給料は出ないです。昇給も少ないので長期的に働くモチベーションも上がりにくいです。

日本に特化しすぎたサービス、ビミョウな事業内容

上で書いたことに関連しますが、経営陣がビミョウだな、パッとしないなと常々感じていました。

身近な社員の声すら聞くことのできない経営層が、ユーザの声を聴いてより良いサービスを展開できるのでしょうか。私はそう思いません。

ヤフコメが荒れたらコメント欄非表示にしたり、新しい決済事業を始めたと思ったらバーコード決済というイマイチ選択をしたり。ヤフーサービスってある程度は便利ですけど、生活必須までにはなっていない。弱い部分だと思います

また残念ながら、ヤフーサービス日本国内限定されており(これはヤフー設立経緯に理由がありますが)、グローバルな展開をしていないのが現状です。

そのため、強力な海外企業との競争さらされることもなく、日本国内というぬるま湯事業環境に入り浸っています

まり面白い事業に関わるチャンスは少ないと感じています


ヤフー親会社であるZホールディングススは、LINE統合を足掛けに海外展開(おもに東アジア)を目論んでいますが、

海外展開されるのはヤフーではなくLINEブランドの方で、ヤフーにいる限りはグローバルな事業に関わることはなさそうでした。

ITの良いところに、世界のどこにでもサービス展開が容易なところがあり、他業種に比べると世界で戦いやす業界なのですが、ヤフーにいる限りはそういったことは出来ないでしょうし、このまま国内のパッとしない会社であり続けるでしょう。

名ばかりユーザファースト

新卒入社すると、まず新卒研修があります

https://anond.hatelabo.jp/20190407192318

こんな感じで虚無研修なのは事実ですが、その中で「ヤフーユーザファースト!!」としきりに言われました。

一方で、こんなリリースが出てました。

https://privacy.yahoo.co.jp/notice/globalaccess.html

EUからヤフーへのサービスが利用できなくなるのですが、それ自体ちょっとアレな判断だと思う上に

Q. 利用中の有料サービスがある場合はどうすればよいですか?

A. EEAおよびイギリスからのみご利用のお客様4月の利用料金が発生する前に、停止や解約などの設定を忘れずにお願いいたします。お手続きについては該当サービスのお知らせやヘルプをご確認ください。

サブスクリプション(月額利用など)のサービスは、EEAおよびイギリス滞在されご利用ができない時間が発生しても当該期間(月定額なら該当月分の利用料金)のお支払いとなりますのでご注意ください。


だそうです。ユーザファーストって何ですかね。

…というのが私がヤフーを辞めたくなった理由です。繰り返しですが、一番の理由給料が低かったことです。2番目は事業がビミョウだったことです。

もしヤフーへの就職を考えているのであれば、似た事業を持っているのLINEとかメルカリかに入る方が良いかなーって思います待遇も良いですし。今ではLINEも同じグループ会社ですが笑

とはいえヤフーにも良いところはあります

完全在宅勤務OK

コロナ流行を受けて、ヤフーは完全在宅勤務になりました。大企業で完全在宅勤務を実施している企業は少ないです。

2020年3月から会社には片手で数えるほどしか会社に行ってません。出勤がないのは非常に楽です。

また、全国どこでも住んでOKというように制度が変わってきているので、子育てタイミング地方移住するといった働き方もでき、柔軟に人生設計ができることは魅力の一つです。ワークライフバランス日本一だと思います。もしかすると世界でもトップクラスに良い労働環境かもしれません。

田舎のんびり暮らしつつ、リモート都内水準の給与をもらって生活する、というのも良いかもしれません。薄給ホワイトって奴ですね。

ネームバリューがそこそこある

海外でのネームバリューはありませんが(大本の米ヤフーは買収されました)、国内ではトップ地位を守っています

エンジニアとしての最初ステップヤフーから始めるのは、その後のキャリアを考えても悪くない選択肢だと思います

技術力もある

優秀なエンジニアが集まっている会社ですし、技術力もあります。私はプログラミング経験があった状態入社しましたが、業務を通じて学ぶことは沢山ありました。3年半で自分スキルも伸ばせました。

就活の時にベンチャーに行くか大手IT系に行くかで迷っていたのですが、この点はヤフー入社して良かったと考えています

たここ数年はアンナプルナという社内プロジェクトのおかげで開発コスト運用コストが下がり、開発に関するストレスが激減しました。今後はその恩恵サービスの質などにも現れてくる、はず…。(それに加えてパッとしない事業計画を何とかしてほしい)

まとめ

私としては、ヤフー新卒で入って数年間は社内でスキルを磨き、その後良い待遇会社転職するのが良いプランだと思いました。長く居続けるのはあまり良くない、というか待遇が悪すぎるし事業内容も面白くないし私のようにすぐに辞めたくなるでしょう。

良いところも悪いところもありましたが、私には悪いところが多く見えて働き続けるモチベーションも下がったため、転職することにしました。

ですが、社内には本当に素晴らしい方達が多くいますし、なんだかんだ国内では影響力のある会社です。日本インターネット黎明期を引っ張ってきた会社でもありますヤフーという会社が今後良くなっていくことを願うばかりです。

2022-03-08

AWS大先生質問なんだけど

インフラほとんど未経験

転職先がどうやらKubernetes構成管理してる会社で俺もその管理に関わる立場になるっぽいのよね

で、正式入社までの間にAWSのEKSにKubernetesで構築したWebアプリデプロイして軽くロードバランサ設定とかそういうの実際に触ってデプロイしながら勉強したいと思うんだけど、

ただそもそも大規模システム向けなサービスだしこれ金額面とか大丈夫かなって心配してる

想定はnuxtサーバ+バックエンドサーバ+DBサーバ適当アプリ作ってバックエンドサーバ辺りを分散構成かにしようかなと思ってる

実際の運用目的じゃないから使わないときはすぐ消すしそんな超スペックみたいな構成じゃないと思うけど、個人ポケットマネー(できれば1万円以内とか)とかでも行えるものかね?

2022-02-17

anond:20220216183232

はっきり言って、日本以外でRPAって全然流行ってないよ。理由として

 ・増田も書いているようにメンテナンスコストが異様に高い

 ・メンテナスをする者のスキルアップモチベーションに繋がらない

 ・自動化したところで、人が行う作業が減るだけで、そこからデータなどのインサイトが得られない


というのが主なんだけど、じゃあ海外だとどうやっているかと言うと、

 ・基本的にはUIを使って操作するのではなく、APIを使って操作する。

 ・よって、APIを有していない社内ツール等はなるべく導入しない

 ・社内で内製しているツールなどもAPIを開発する(今だとフロントバックエンドは分離しているのが多いのでそのまま利用する)


として、極力一度作った物のメンテナンスを減らしている。(結局メンテナンス必要だが)ただ、日本では経営者ITに弱いことが多いので、一見コストが減らせるように見えるRPA選択してしまう。


物流と書かれているので、WEBアプリではなくWindowsアプリみたいのをポチポチしないといけないケースも多々あるかと思うしアプリニッチ過ぎて、APIなんて付く見込み無いとかあるだろうけど、一人でやるのは心が壊れるのでRPAやるにしても、専任チームつくったり、派遣とかを雇ってチームで回すようにしてったほうが良いと思いますぞ。

2022-02-11

28歳専門卒Webエンジニアなんだけどガチ人生相談したい

転職活動中で医療ベンチャー初年度年収650万のところに内定したんだが、

どうやら話聞いてると最近資金調達終わって今頑張って作ってますよーの段階らしい、現時点では全く利益出せてないし先行きが本当にわかんない

資金調達額的には2,3年くらいは食えてけそうな気もするけど

正直話聞いた感じ技術スタックとか構築難易度から考えても相場よりだいぶ高い年収だし、起業家社長や人事がエンジニア相場観わかってない感じがあってそれも逆に不安だったりする

多分俺の市場価値より多分かなり高い額になってる、転職やってる自分相場観としては「500万までのスカウトは山程来るけど600万はあんまり来ない」ってレベル

一応リーダー経験とかフロント/バックエンド両方担当してSaasを1から主導構築とかテックリードかいろいろ経験はあるけどどれも小さい会社だし専門卒だしPHPキャリアの中心だしそんなもんかなって気はしてる

正直多少給与帯下げても好きな技術スタック会社狙って安定狙いたいみたいな気持ちはあるけど、

でもこの年収肩書あれば婚活で戦ったとき有利かなぁとかも思うしどうしようかなって、

先行き怪しいベンチャー危機感抱きつつも勤めることにして年収で釣って仮に婚活成功したとして年収100万くらい下がったら簡単に捨てられちゃいそうだよなぁって……

技術職だし倒産して仕事クビってなっても食っていけなくなるみたいな心配は全くしてないけどさぁ

どうしたらいいと思う?

2022-02-09

その辺の技術者知識で負けないくらいのふるすたっくえんじにあになりたい

機械工学大学で学んだ。機械系4力学さわりだけなら大体やったがもう忘れている。

・切削加工はけがきフライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ3Dプリンタでなんでも作れるらしいが、3Dプリンタは触ったことがない。

CAD大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。

シミュレータANSYSマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。

電気工学はだいぶ勉強不足。簡単回路図チップ製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。

化学系は全くの無知大学受験で知識は止まっている。物性物理的なところも無知

数値計算PythonMatlabちょっとできる程度。ライブラリを使った行列計算簡単ニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分常微分方程式を調べて思い出せばできる程度。測度論とか特殊積分かいわゆる大学数学的な道具が必要になる解析はできない。

競技プログラミングちょっとかじったがやめてしまった。むずかしすぎた。

機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定1級落ちた。

バックエンドSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった&謎のSegmentation Faultで苦手意識を残したまま。Go?Rust?なにそれおいしそうだね。

クラウドAWSマニュアル通りに使っている程度。1から設計なんてできない。なのでAWSソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。

ネットワーク系とかセキュリティ系は全く勉強不足。応用情報ギリギリ合格できる程度の知識しかない。わかるようにはなりたい。

フロントエンドFlutter勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離ありすぎてよくわからない。javascriptはjQuery一強時代ちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript?なにそれおいしそうだね。

ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。

全部中途半端だな、、、

2022-02-07

anond:20220207165714

テレワークが進んで転勤という概念も変わりつつあるよね

主に工場とかBtoCの地域営業かになるのかな

バックエンド事務オンライン営業システム担当なんかは北センティネル島でも仕事できるんちゃう

ごめん北センティネルはいいすぎたわ

2022-01-30

最近はどうかわからないけど、実は俺も流れてITに来た

普通高卒で賢くはない。高校卒業後はフリーターバイト転々としてたけど、体力ないから座ってできる仕事がいいよなと思って、オタクだったしゲーム会社受けたらデバッグ採用してもらえたのが10年くらい前。そこから会社の人に教えてもらったりしてプログラミングも始めて今はゲームバックエンド書く仕事させてもらってる。だからどうしてもITは一発逆転できるって思っちゃってるところは実際にある。IT以外でこんな俺に座ってできる仕事はあるかと言うと無かったと思う

2022-01-29

サーバーレスサーバーがないわけではないように、セックスレスセックスがないわけではない

その存在がないかのように思える仕組みがあるだけなのです

セックスユーザー意識させないだけで、セックスバックエンド物理的に存在しているのです

それをベアメタルセックスと呼ぶのです

セックスクラウド時代なのです

必要ときに、必要資源で、必要セックスをすることが可能時代なのです

コンテナ単位でのセックス可能なのです

知らんけど

anond:20220128174620

専門家の人はレガシー言語までなら付け焼き刃でもなんとかなるみたいよ。

でもフレームワークの話になってくるとバックエンドフロントエンド理解してないと何もできないから途端にできなくなる模様。仕事講師することあるから知ってる。

 

でもやっぱり本人の努力次第だけどね。かじりついてればなんでも覚えられる。

ようは本人がほんきかどうか。

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

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