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

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

2018-10-14

渋谷にあるニュース会社を辞退した話

少し前になるが、転職活動の一環で難易度が高いと言われているニュース会社リクルーターを通して受けてみた。

SNS勉強会を通じて、優秀な人材がいることは事前に分かっていたし、勉強会で実際に話してみるとただ有名なだけのエンジニアとは違い、技術にもビジネスにも明るく仕事が出来る事が直ぐに感じ取れたからだ。相手自分ことなど覚えてはいないと思うが。

時を同じくして同僚も受けていた事が分かり、同僚も辞退をしていたのでどんな感じだったか情報交換を行った。

面接を通してミスマッチが発生しなくて良かったと思っているので、その記録を残してみる。

私のキャリアは、ソフトウェアエンジニアを約10年ほどサーバーサイドのプログラムを多く書いており、十数名規模のマネジメント経験がある。

応募ページを見ると、大量にポジション無尽蔵に羅列してあり、何が何なのか正直よくわからなかったのでポジションサーチというやつに申し込んだ。

自分キャリアから適切なポジションを案内してくれるらしい。

まずここでミスマッチが発生した。先方からフロントエンド関連のエンジニアポジション提案され、戸惑いながらも面接に進んだ。経歴書にはフロントエンド業務で取り組んでいたと書いたためであろう。なお、面接の前にオンライン簡単コーディングテストが行われた。

面接は1日に連続して数人と行うスタイルで、このやり方は初めての体験だった。

最初の人は現場の人だったのであろう。非常に初歩的な事を聞かれた。技術的に深いコミュニケーションが出来ず、少し深ぼった話をすると逆になんですかそれはという反応をされたので、レベルが高くない人なのかと察し適当に流すことにした。

なお、コーディングテストの結果はどうだったのか評価を教えてほしいと伝えると、自分もこの問題はよく分からいからと言われた。一体何のために行っているのかテンションが下がる話である


次はマネージャーとの面接だった。どういうチームがあるのか組織的な事を説明され、相手会社アーキテクチャ説明された。その上でどう改善するかという問題を出された。

こういう面接方法もあるのかと思いつつ、もし前提がこうであればこう改善したほうが良いという提案を何個かしたが、それはこういう理由で出来ないや、今は忙しくて取り組めないという事を返された。隠れた条件を後付けで出されるので、なんかズレてるなと感じ、組織的課題を聞いてみたところはぐらかされた。

面接によくある、最後に何か質問はありますか?と問われたときに、面接の中で聞かれたことを逆質問し、その課題にどう取り組むかの意見を聞いたところ、適当な感じに返された。

この時点で微妙な人たちが連続して続いたので、私の中では辞退をしようと決めていたのだが、是非2次面接に進んでほしいという案内を受けた。

てっきり1次と2次を連続してやったと思っていたが、この日に受けたのはどちらも1次面接らしい。


リクルーターには別のポジションで受けたいこと、可能であればもっと優秀な人か勉強会で登壇した人と面接をしたい事を伝えたが後者は叶わなかったので辞退を申し入れた。辞退の理由は、面接した人と一緒に仕事をする事になると心労が絶えない事を直感的に感じ取ってしまたからだ。


同僚はバックエンドというポジションで直接応募しており、情報交換した感じでは面接官は別の人のようだった。

聞いた話なので詳細を書くことは出来ないが、Kubernetesの本に関わっている有名な人が出てきたようだったが、そのプロダクトの話をしても全然詳しくなく、実際にサービスで使っている自分の方が詳しくてがっかりしたそうだ。今取り組んでいるプロダクトの課題目的、背景を聞いても、よく分からないと返されてしまい、萎えしまったために辞退した模様。その同僚はフリマ会社も受けており、きちんと分かっている人が出てきたのでそちらに行くらしい。


から見るとイケイケな会社に見えても、実際はそんな事は無く、一部の優秀な人がまわしてるんだなと思い悲しくなった。

2018-10-13

転職について(求職側編)

前置き

https://anond.hatelabo.jp/20181005233454

↑これを書いたものです。書いたとおり会社を離れることになり、次の職場も決まっている。8月から9月いっぱい活動し、複数内定をいただいた。アラフォージョブホッパーだが、人生の中で最も就職活動がうまく行った時期だった。別に自分が優れているわけでも何でもなく、超売り手市場の売り手職種だったというだけである。しばらくは転職したくない。

以前高内定率のハイスペックジョブホッパー増田がバズっていたが、自分は平凡なおっさんジョブホッパーなので、多分この増田は誰かの役に立つと思う。

※例によって身バレすると現職と次職と面接受けた会社迷惑かかるのである程度ぼかす。

スペック

これを書く理由

はてブGoogleもすっかりアフィスパム汚染され、ビズリーチやワークポートへのアフィブログばかりだったから。増田に書いたのもタダで拡散するため。

正直、並レベルの実力があるWebエンジニアならエージェントビズリーチを使う必要はない。ヘッドハンティングがほしければ、Wantedlyレジュメ登録して、Qiitaに何個か記事を投げておけば勝手に来る(役に立つかどうかは保証できないが)。

Qiitaじゃなくて増田に書いたのは、Qiitaテック系の記事投稿すべきものQiitaにある転職系の投稿は全部ゴミだと思っているから。そもそも規約違反だしね。

使ったサービス

Green

エンジニア転職定番である。ここにレジュメ登録しておくと、確度の高いスカウトが来たり、「気になる」が届いたりするので、これを利用して気になった会社コンタクトを取りカジュアル面談をする。

職務経歴書ポートフォリオも書面ではなくWEB(今流行りのサーバーレス)で作った。個人情報もあるので認証付き。去年あたりはやったOSS職務経歴書はやっていない。

試しに何社か自分から気になるを押してみたがほとんど反応なかった(自分ポンコツだったからもしれないが)。基本的オファーを待つサービスである

Wantedly

去年上場時にDCMA悪用炎上したWantedlyであるはてブにいる理想主義者人達はこのサービスを嫌うが、正直なところ代わりになるサービスもないので使った。採用側のときも使ってたし。

ここもレジュメを充実させて、ポートフォリオへのリンクを張ってスカウトを無制限に受け取るように設定。スカウトが来た会社の中で、特に気になるところにコンタクトを取ってカジュアル面談をする。社員数名のガチスタートアップから上場したばかりの有名ベンチャーまでいろいろなオファーが来る。流石に創業メンバーWantedly募集しているようなところはお察しなのスルー

この2つで合計15〜20社ほどとカジュアル面談し、数社を除いてほぼ「ぜひ本選考に来てください!」となった。旧来的な転職活動書類選考ほとんどなかった。というか、レジュメポートフォリオのおかげでほぼ書類パスできていたと思う。いちから自己応募をせずにダイレクトリクルーティングを最大限に活用した。

ヘッドハンター(エグゼクティブサーチ)

今回は転職エージェントは使わないと、固く心に誓ったのだが、Wantedlyに以前から登録してたり、会社ブログを書いてたりしてたせいか何社からメールが来たり、会社電話に連絡が来たりした。

正直なところ、数千万プレイヤーでもない限りこの手のサービスを使う意味はないと思っているのだが(実態は単なるプッシュ型エージェントだし)、興味本位で数社ほど会うことにした。結果1社だけいい感じのカジュアル面談をセッティングしてきたので、それだけ会うことにした。

使わなかったサービス

人材紹介(転職エージェント)

上記の通りヘッドハンターは1社だけあったが、転職エージェントは使わなかった。以前の転職活動ときに、的はずれな会社を紹介され続けたのですっかり嫌になっている。採用から見てもアレな人の紹介が多かったし。

ジョブホッパー転職なれしているせいで、レジュメ添削面接対策スケジュール調整も年俸交渉不要で、自分にかかる高額な採用費のほうがマイナスになるからである(Greenもそれなりに高いけどね)。

あれは一見すると採用側が負担するように見えて、実は最終的に求職者側にも見えない形で金銭負担がかかる。交渉無しで全社希望額よりプラスオファーをくれた。転職エージェント基本的ポジショントークしかしないので、あまり頼らないほうがいい。ただ、大企業に行きたければ意味あるかもしれないが。

リファラ

実は転職活動を全くしていなかった頃に知人に誘われたのだが、今回あえて連絡を取らなかった。

リファラルはM社(田町)やM社(六本木)のようなエリートベンチャーが、ハイスペックエンジニアを採るのにはいいかもしれないが、自分場合その知人の会社に会いに行く→不採用or辞退なんてなったら気まずいので行かなかった。

SNS

ちょうど自分活動を始めたとき、某有名フロントエンドエンジニアTwitter仕事くれと言ったら大量のDMが届いたそうであるハイスペックエンジニアならこの方法有効だが、業務以外に大きな実績もないエンジニアには無関係な話である

他の転職サイト

以前は使ったのだが、例えば@typeDODAなどは全く関係のない職種メール爆撃がひどかったし(東建コーポレーション夢真ホールディングス、あと外食ドライバーとか)、ビズリーチは圏外。FindJobはGreenWantedlyに比べて求人の質が下がっている気がする。リクナビNEXTは行きたい会社がまったくない。Miidasは眼中になかった。

転職ドラフトは長い長いレジュメを書かされる→レビューでやり直し→オファーが来ても通常の採用フローに回される、というのを見て工数オーバーだと思って使わなかった。通常の採用フローがある時点でドラフトでも何でもないやん。

ハロワ

東京Webエンジニアハローワークで本気で仕事を探すことなんかあるんだろうか(嫌味でも何でもなくて素)?

東京以外で何回か利用したことあるが、求職者相談に関してはいっその事民営化して、悪名高いR社にでも委託したほうがマシな気がする。少なくとも金がかかっている分彼らのほうが真剣であるし、失業保険だけせしめるだけで就職する気のないような輩は追っ払ってくれるだろう。

選考辞退したところ

以前の転職活動自分から辞退することはほとんどなかったのだが(選べる立場じゃなかった)、今回は落ちることも少なく多忙を極めたため、何社か辞退することとなった。

スケジュール調整が遅い、連絡が遅いところ

ほとんどの会社コンタクトから1営業日程度でアポイントを返してきていたのだが、何社かは信じられないほど遅い会社があった。

余裕のをとり広く日程を提示したにもかかわらず、返事に1週間もかけてよこしてきたり(当然他社のアポイントが入っている)、相手側都合で約束していた日程が合わなくなりリスケ依頼してきたり(当然他社のアポイントが入っている)。こういうところは人事が回っていないか面談するエンジニアを用意できないかのいずれかで、入社してもいいことがなさそうなので辞退した。

土日や深夜に連絡が来る

自分面談自分業務終了後希望しておいて勝手なのだが、流石に深夜未明とか日曜日メールを寄越してくる会社は、労働環境問題がありそうなので辞退した。休むときは休むべきである

スキルミスマッチ

自分側の問題だが、ハイスペック系やフルスタック系を求めてくる会社カジュアル面談の時点で辞退した。まず次の選考が通らないし、間違って採用されても多分自分が苦しむことになるからそもそもなぜ自分スカウトを出してきたのかが謎だったが。

結果

辞退以外のお見送りが3〜5社ほどで、内定が2〜4社ほど。それ以外は選考中に辞退。上に上げたような理由がなくても、スケジュールが合わずに辞退した会社もある。

内定をくれた会社はいずれもレスポンスが早く、スケジュール調整もかなり早くしてくれた。辞退防止のためか人事もかなりフォローを入れてくれる。新卒はかなり辞退率が高いそうだが、中途採用も高くなっているのであろう。最終的に辞退する会社には申し訳ないが、丁寧にお詫びするつもりである

年収も30〜70万円ほど上がった。現職と同じから+50ぐらいで希望していたが、思いの外高く評価いただいている。あとフレックス制や副業OKストックオプションなど、福利厚生労働条件も今どき風になった。しばらくは転職したくない(2回目)。

追記

なんかトラバフリーランスがどうのとかって言ってるけど、自分フリーランスになってもせいぜい800〜900万前後年商(年収ではない)をうろうろすることになり、社畜で500〜700前後でうろうろしたほうが楽だと思ったので社畜を続けることにした。技術ゴリゴリの人とか金金金の人ならいいんだろうけどね、そういう人は楽勝で1000超えるしw

あと年収1億のやつが転職サイト使うわけ無いだろ、少しは考えろw

追記2

バックエンドはどうだと言われてますが、スキルによるが基本的フロントエンドよりも年収は高いです。フロントHTMLコーダーレベルの人も含んでいて参入障壁も低いしね。領域が違うので単純比較は難しいですが、同じぐらいのレベルの人で50〜150ぐらいの差はあるんじゃないでしょうか?

ただSSRとかBFFとかその辺を出来る人は逆に年収高くなります。あとサーバーレス。この辺をちゃんと出来る人(開発から運用まで考えられる、例えばCI周りとかね)はバックエンド一本の人よりも年収高くなりますが、フルスタック的なスキルを求められるので並レベルではなくなります

あと職種関係ありませんが、年齢行ってるとある程度マネジメント経験求められます。正直なところ技術的なとんがり度では若者に勝てるわけがないので(フロント界隈の有名エンジニアは皆20代)、この辺で勝負していく必要があります。年齢的な不利は老獪な社畜力で乗り切りましょう。

追記でいろいろ書くのも限界なので、そろそろその3書くか(スーツがどうとか面接の内容とか)。どうせ有給中で暇だしw

2018-09-29

メルカリアプリってそんな特別か?

若干重いし、特筆すべき所もない普通アプリに見えるんだが

技術者講演会かに集まってるの面白い

バックエンドは興味あるが

2018-07-30

anond:20180730225820

なんでelastic searchってキーワード出したのか分かんねえのかよ……

そこら辺の閾値決めて適当無視してくれるんだよ。最近検索エンジンバックエンドは。

コレが増田の言うAIっぽい挙動をしていないってならそうかもしらんが、こういう検索エンジン利用して作られてるAIフロントエンドとか結構あるぞ。

りんなとかそうじゃないっけ?

2018-07-13

Microsoft Teamsの無償提供開始とその反応見て思った

完全な外野適当な思い付きを書いていく。

大体の人の頭の中で「覇者Slackに挑むTeams」な構図になっているが実際はそう単純ではない

公正な比較はできないんだけど、アカウント数および有償プラン契約数でいうと少なくとも国内SlackはTeams(Office365)の足元にも及ばない。

https://www.publickey1.jp/blog/18/slack.html

国内だとSlack無料アカウント含めて50万、有償プラン契約数は15万というのが上記記事に書かれてる。

世界だと有償プラン契約者数が300万人以上、ということらしい。単一機能サービスでここまでの規模に成長しているのはまさにチャットツール市場覇者と呼ぶにふさわしい。

一方のOffice365なんだけど、Teamsを今まで利用可能だった商用の有償プラン契約数は1億3500万人のMonthly Active Userと下記の2018年1~3月期の決算資料に載っている(スライド9枚目)。

流石に契約者数は明かしてくれないらしいが、Teamsを今まで利用できなかった一般消費者向けの契約者数は約3060万人契約とのこと(スライド10枚目)。

https://view.officeapps.live.com/op/view.aspx?src=https://c.s-microsoft.com/en-us/CMSFiles/SlidesFY18Q3.pptx?version=2b0076e2-b5c3-fee9-75df-dc8e78688560

ちなみに少し前に発表されたSurfaceGoの国内版にだけバンドルされて大顰蹙を買ったOffice売り切り版は収入が16%落ちてるらしい。

クラウドへの移行が着々と進行中、という今更説明するまでもない状況みたい。

契約者数はともかく、実際の利用者数、コミュニティ成熟度などはSlack圧勝(私個人見解)

契約者をいくら誇ったところで、Teams利用者の声なんてあまり聞こえてこない。下記のブコメでも「実際に利用して具体的な意見を書いている人」は驚くほど少ない。

http://b.hatena.ne.jp/entry/s/pc.watch.impress.co.jp/docs/news/1132746.html

Office365企業で大々的に導入している職場をいくつか経験した自分感覚としても、Teamsをまともに利用している職場は見たことがない。

存在自体を知らない、モノ好きの情シス適当に使ってる、大規模導入の検討初期段階、といった感じのところが多いのでは?

利用できる契約者は多くても、そもそも存在自体があまり知られてない、というのがMicrosoft Teamsの現状。

Slackそもそも単一機能を売っているという関係上、契約者はチャットツールを使うために契約しているわけで、Slack契約者≒Slack利用者となるわけだが

Office365そもそも情シス買い切りOfficeカウント地獄から解放」というお題目や、

メールサーバ運用から解放」などといった感じで、Teamsを主目的の一つとしてとらえているユーザーがそこまで多くない感じ(そもそもOffice365リリース当初には無かったサービスだし)。

なので、Office365契約者>>Teams利用者となる。

無償化ユーザー数拡大のための施策なのか?

個人的な見解は「ユーザー数拡大ももちろん視野には入っているだろうが、認知度向上の方が比重高いのではないか?」という感じ。

まずはニュースサイトが分かりやすい構図として「MSSlack対抗サービスがついに無償化」みたいな記事を出せば「あぁ、うちが契約してるOffice365にもチャットツールあるんだ」と知ってくれる既存契約者も多いだろう。

それによって利用率向上を狙っているのでは、というのが自分の予想。

Slackへの攻勢をかけるという線も薄い。

わざわざ自社より小規模でロイヤリティ高くて引き剥がしにくいユーザーを狙う意味がない。

そもそもOffice365自体契約者数は絶好調で成長中だからね。

そもそもSlackの2/3ぐらいの価格でなんでも付けてるOffice365必死な防御策こそTeams位置づけ

よく言われることだが、Microsoft TeamsSlackパクリから始まったサービスだ。

それは間違いない。

ただ、現状のSlackとはターゲットユーザーが違う関係上、進化の仕方が微妙に違っている。

コミュニケーションプラットフォームという大枠の括りは一緒でも、自社内にチャットツール以外が無く、外部との連携機能拡張をするSlackとは対照的

Office365ビジネスプランにはMicrosoftIFTTT的なFlow(これも始まりIFTTT的な感じだったが、もはや全くの別物になった)や、

Microsoft版TorelloなPlanner、WebOffice(プランによってはクライアント版)、SharepointExchange、何でもありだ。

流行り物はどんどん巻き込み、投げ売りといってもいいレベル価格付けでユーザーを囲い込んでいってる。

Plannerが無償版なしだったり、Flow無償版がお遊びレベルの内容なのと違って、Teams無償プランがここまでのレベルなのは

ひとえに「Slackの脅威がヤバいからだ。

単一サービスで300万以上の契約を勝ち取るクオリティリテラシーの高いユーザーによって構成される成熟したコミュニティ

チャットツール無償版なしではOffice365契約が切り崩されかねないという危惧もあるのだろう。

チャットツール代替するものとしてよく挙がる「メール」はOffice365重要位置にいまだあるわけで、

下手にSlack導入して「あ、これメールサーバ要らんな」みたいなことになると、Office365自体契約も危ういわけで、必死になるわけです。

あとはいくつかのブコメに反応して終わり

まずはSkype for Businessを何とかしろ

Teams統合して消滅っていう方針が決まってるよ。

もう諦めて Slack 買収した方が良いのでは。

諦めるどころか、これから防衛戦頑張らなきゃならないんですよ。

買っても大したユーザー増にならないし、どうせ既存ユーザー逃げるし、金の無駄しかいか

買収の線は薄いんじゃないですかね。

Trello対抗にとりあえず作りましたで後は放置のPlannerやWunderlist買収してから放置ToDoとかと同じ末路を辿る予感しかない

PlannerやToDoバックエンドAPI整備がやっと最近ひと段落したので地道に改善はしてたみたいですよ。

そのおかげでまだ不十分だけどFlowトリガーアクションが追加されたしね。

僕らのYammerが転生したってこと?(・・?)

Yammerって気軽に投票募れるぐらいしかTeamsに対する優位点見出せないんだけど、

ちょっと前にデスクトップアプリ出してきたりと、まだなんかやろうとしてるみたいなのが意味不明。

結構な額で買収したから、おいそれと損切りできないのかな?

これ系のサービスは気まぐれで終了されると洒落にならない。無償大丈夫か?

Skype for Businessを生贄にするぐらい今のMSはTeamsに本気だから、当分大丈夫だと思う。

その他クオリティに関するコメント

上にも書いたけど、はっきり言ってチャットサービスとしての完成度はSlackが上だと思う。

Teams結構使ったけど、よく言えば頻繁に機能追加される。悪く言えばそもそも機能が足りてない。

1年以上前リリース当初は場所によってIMEONにできなかったりしたしね。

あと機能追加もよく言えばコミュニティベースから機能要望を挙げて、それに賛同者を募って

多数の賛同を得られないと開発者の目に留まりにくい。たまに投票数の低い案が優先的に実装されたりもするけど

基本的には投票数の多い案件から実装機能が選ばれることが多い。

ただ、わかってる人がゴリゴリ使い倒す、っていう方向でクオリティを上げてるSlackに対して

TeamsあくまでもOffice365との密な連携主題において、外部とも連携できるように、っていう方向なので

ターゲットユーザーそもそも被らないのでは、と個人的には思ってる。

Slackに満足してる人はOffice365に囲われてるおまけって時点でTeamsの印象悪いだろうし、

Office365についてくるTeamsで十分な人はチャットツール単体に1000円/人月なんて払わない。

MS側もSlack対抗というより、Slack開拓してくれたチャットツールという新たな魅力でOffice365契約数を増やしたい、という感じに見える。

2018-06-29

anond:20180629145126

言われてみればそうだな。

や、httpからhttpsの転送バックエンドでできるけど、ドメイン変更はもうひと手間かかるってことじゃないの?

それにしたって、べつに2,3日とめてドメイン変更すればいいじゃんって思うけどなぁ

2018-05-30

anond:20180530094058

そう。業務系のバックエンド以外での採用がまず無いから、カジュアルに語れる存在ではなくなった(普段使いしない言語になった)ってこと。

PerlCOBOLも今もこの世界の片隅で使われている言語なのは間違いないが、鉛筆や筆代わりに使われることはない訳だろう。

Javaはもう、そういう言語になってしまったって事よ。

2018-04-29

巨大トラフィックをさばくシステム

TwitterFacebookのようなサービス日本発で作りたいね

インフラクラウドも併用するとして、バックエンドはどうやって作ればいいかな?

Elixir/Erlangは、使いやすいでしょうか?

2018-04-25

介護が始まりそうだから仕事辞めようかな

親の介護しながら

家で仕事ってできるのだろうか

プログラミング可能です。

一通りフロントエンドからバックエンドまででWebサービス作れるって状態です。

Webサービスは作るのは簡単なのだが、

それでお金が稼げるかはまた別問題なんだよな。

2018-03-23

anond:20180323154414

AIバックエンド部分を作ることを一般web系とは呼ばん…

AI使ってても実質awsAPI叩いたりしてるだけだったりして、そういうのはもちろんREST APIぬっこぬこしてるだけだからweb系という括りになるけど。

2018-03-20

文系エンジニアなんて死ねばいいのに

文系エンジニアなんて死ねばいいのに

俺、Webサービス作ったんすよ(Rails

俺、iOSアプリ作ったんすよ(Swift

俺、Macbook使ってるんすよ(タッチバー付13インチPro

俺、プログラミングスクールプログラミング教えるアルバイトしてるんすよ(そいつはそのスクール卒業生

これぞ量産型文系エンジニア()

懇親会で「皆さん嫌いな言語とかフレームワークはありますか?」と話題になると私は即座にRailsと言う。

すると文系エンジニアはみんな嫌な顔をする。

そこでちょっとお話をすると皆怯んじゃう。

「あのコマンドを打つと中で何が起きてるか知ってますか?」(知らない

ActiveRecord?生でクエリいたことあるインデックス意味くらい知ってるよね?」(書いたことない、適当なこと言う

へーその作ったサービスURL教えてよ

3分

「alert('XSS')」

Session?Cookie?(何それどんな味のクッキー

CSRF?(企業理念か何か?

百歩譲って学生エンジニアならまあセキュリティ無知なのは分かる。

しかしだな、文系エンジニアは「俺もハッキングしたい(笑)」な勢いで詳しく解説することを要求してくる。非常にウザい。

"

お前はよぉ!自分で探すってことをできねぇのかよ!?

"

しょうがないので優しく解説すると「君ってハッキングとかしてそう(笑)」「君将来ハッカーになりそうだわ(笑)クラッキング的な意味で)」

死ねよ。

文系エンジニアはこれだけではない

俺、Git使って開発したんすよ(GUIのSourcetree

え?バグちゃんテストしたんだけどなぁ(完全手動テスト()

デプロイ先は9割Heroku。(HTTPS対応

AWSGCP登録はしたものの使い方が分からなくて結局放置

SSH証明書を使わずパスワードオンリー

pwdcdしか知らない(Makefileを作ったことないからいつもネットコピペコマンド

見た目重視のTerminal(ネットコピペ設定)

最近聞いた文系エンジニアもっと面白い

新規事業を開発してる文系エンジニア集団がいた。

開発は順調、プロモーションをかけていざリリース

はいゴールデンタイム鯖落ち。復旧した時にはゴールデンタイム終了のお知らせ

理由CDNを刺してない、貧弱なプランの鯖(勿論ロードバランサなんか使ってない)

噂による無線LANルーターの設定も出来ないレベルらしい。

でも彼らは一応優秀な文系エンジニア高学歴サービスも作ったこともある、それなりの実績も持っている。しか文系だ。

こういう奴らがいるかちゃんとしたエンジニアを軽視される。黙って営業職に転職してこい。

まあでも大学じゃ作者の気持ちしか考えてないのだから当然のなのかもな(笑)


追記

残念な理系名前を書くだけ一発採用派遣SIer対象としてない。論外だ。

給料が安い?

そんなことは無い。400万以上貰える会社内定もらっているか嫉妬も不満も特に無い。

だがしかし、ムカつく。

そんな奴が同期にいたら蹴り飛ばしてやりたくなる。

そうさ、今はSwiftiOS時代だ。

だが見てみろ、あいつらのアプリバックエンドが無いんだぞ?意欲は認める。だがそれで胸を張ってiOSエンジニアなんて無理があるだろ?

2018-03-15

フロントエンドはいいぞ

バックエンドのように地味で制限も多くいつまで経っても新しいものがあまり出てこない退屈なところとは違う


から次に新しいツールが出てくる

同じツールばかりで飽きることがない

案件で新しいのを使ってみて、次の案件ときにはもう次のツールが出てきているから使っていける

同じものばかり使って新しい体験がないまま同じようなことの繰り返しという退屈さがない

常に新しい体験ができる


さらにはツールが多すぎる分、ツールも選び放題だ

自分にあったものを使えばいい

JavaScript 自体ウェブだとこれ一択だったから、オブジェクト志向だったり関数型だったり比較的いろいろな使い方ができる

それぞれに合わせてライブラリがあるから好みの使い方をすればいい

型がほしいならtypescriptなどのaltjsもあって自分の好きなもので作れるわけだ

一部○○するならこれ、などと言い切ってる人がいるがそんなことはない

いいところもあれば悪いところもあるし、欠点があるからそれを補った別のツールが出てくるわけだ

目的に応じたもの自分が好きなものを使えばいい


ついていけないという人もいるが、新しいのが出続けるというのを理由に避ける必要はない

新しいのについていけない、めんどくさいという人は古いのを使い続ければいい

新しいものを使うかどうかも自由

未だに jQuery やそれと同じくらいの時代からあるライブラリのみのサイトだって普通にある

それが悪いということもない

新しいもの価値があるなら使う、ないなら使わない

そういう選択もありだ

2018-03-12

どこまでがフロントエンドのやることなんだろう

私がいるところは、プログラマ/システムエンジニアフロントエンドエンジニア/バックエンドエンジニアとかの区分がなくひとりでなんでもやるところです

一応フロントエンドが好きで得意だと自称はしているもの一般的フロントエンドってどこまでするのでしょうか


デザイナがするような部分

ここは当然でしょう


最近では SPA のページも多いので単純な HTMLJS ではなくフレームワーク必要とされることもあります

ここもブラウザ側の話なので必要でしょう


SEOの都合などでJSレンダリングじゃなくサーバサイドレンダリングで、サーバから受け取るHTMLの時点で表示できる状態になってることを依頼される場合もあります

その場合サーバサイド言語に応じたテンプレートエンジンも使います

PHP なら BladePython なら jinja、 Node.js なら ejs という感じ


JSコードテストしたり gulp などのタスクランナーwebpack などバンドルツールを使うので OSコマンドラインツールも使える必要があると思います


サーバサイドの言語は別の人が作るにしても自分環境でそれを動かすためにサーバ構築は出来たほうがいいでしょう

VMOSインストールしてウェブサーバインストールしたり

Vagrant, Ansible 等で管理されているなら、設定ファイルを書くことはないにしろ実行する方法エラーが起きたとき簡単対象方法くらいは知っていないと不便かと思います

ウチの場合各自LinuxVMインストールして Ansible でという使い方なので気づきませんでしたが、考えてみたら全部設定済みの VM データを配布してくれるということもあるのかもしれません


データによって画面表示を変えるときに、それに応じたデータを作って画面を確認したいことがあるので、mysql や postgres などなどデータベースの知識必要になることがあります

SQL 書けなくても pgadmin みたいな GUI ツールで表を書き換えればいいのですが最低限の仕組みは知っていないと苦労しそうです

完全にフロント/バックが切り離されてるところなら、フロントエンド開発者向けにデータベースは使わずテンプレートエンジンに渡ってくるデータを好きに設定できる機能が用意されてるのかも?とも思います

サーバサイドの処理は不要クライアントサイドの動きのみを作るわけですから、決まった場所JSON ファイルデータがそのまま使われるならデータベースの存在を知らなくてもいいですし


ここまでできたらバックエンドよりフロントエンドのほうが何でも出来る人みたいに思えます

あとはサーバサイド言語を書ければもうサービスが作れてしまます

でもこれぐらいできないとすごく不便で、すぐに他の人に頼らないといけなくなるように思います

サーバ冗長化とかそういった部分はかかわらなくてもいいと思いますけど、Linuxデータベースなんかは自分でどうにかできないと周り誰もいないときに動かなくなったら作業進められななんてことがありそうですし

2018-03-11

自分自己肯定感が弱いと感じている

日頃、自分の興味のあることに関する課題発見し、それを解決するためにアプリ(小規模だけど)を開発し公開している。作ったものがたまにバズることがあって、その結果1日の広告収入が1万円を超えたこともあった。しかし、定期的に作ったアプリに対して使った技術要素やコーディング量を見返した時、これぐらいのものはxxさんなら自分より短時間かつ高クオリティで開発できるなと思うことがあるのだ。

興味があることに自分課題発見し実際に手を動かしているのですごい!みたいな話を聞いたことがあるが、理解はできても共感ができない。

常にネガティブ感情を抱いているわけでもなく、難しい箇所をうまくコーディングできた時は自分のことを天才だと感じることや、ミドルウェアを含むバックエンドからフロントエンドまで1人で開発できるようになり、昔の自分と比べて成長したと感じることはある。ただ、これらのポジティブ感情は一瞬で終わり、あっという間に上に書いたようなネガティブ感情自分支配するようになる。

レッドコーダーやKaggle Masterになるか未踏に採択されるなどのレベルに達すれば、自分を認めることが出来るような気はしているが、あいくそこまでの能力は持ち合わせていない。

https://anond.hatelabo.jp/20180311003723 を見て書きたくなった

2018-02-20

ヲタクエンジニアになりたい

わい情報学部就活生.ヲタク文化を支えているIT企業就職したいと強く思っている.お硬い企業で死んだ目でキーボードタカタするよりも,興味のある分野でキーボードタカタしたい.

ちなみにわいはWebフロントバックエンドばかりやってる.だからとりあえずWeb系かなって考えてる.

国内ヲタク企業は幾つかある.以下は順不同で適当に挙げたものである

pixiv
言わずもがな最近は絵の他にもグッズ販売即売会での決済手段提供など,幅広い創作活動に手を広げている.インターンにも参加したけど,良いところしか見つけられなかった.ここはマジで入りたい.
ドワンゴ
ニコニコ動画運営元.動画を中心に,ここも色々とやってはいる.が,最近は色々あって有料会員が激減したね...たつきを返して...
とらのあな
Twitter広告でよく目にする,「ヲタクエンジニア募集」.エンジニアはあまり居ないらしいが,だからこそ色々できそうで面白そう.

2018-02-12

anond:20180212215214

開発者じゃなくて、ビジネス系なんだけど、BI(Business Intelligence)のプラットフォームデータ分析する職種は、いまはどこもSQLの基本知識がほぼ必須なんだ。加工前のデータ抽出用として、あくまでも基本的知識だけ必要なのかもしれないけど

もともと少しコードを書いてたこともあったので、日曜大工的に自分サービス作ってみたいと思ってます

なのでSQLの基本をおぼえたらバックエンド実装の仕方も知りたい

2017-12-01

ツイッターブログ仕事関係の人も読んでいるので、ここで書く。ちょっとした事情Uターンして、とある地方のしがないWEB屋で働き始めたのだけれど、半年経って、もうこれは限界かもな、と思っている。


コードレビューが無い

社員が少ないし時間がないのもわかるのだが、コードレビューがあることによって、バグコード書いた人の目に届かない部分の影響への指摘などができると思うのだ。


テストしない

フロント状態管理が大変なので、限界があると思うんだけど、バックエンドテストコード書いて、ユニットテストくらいはやろうぜ、と思っている。まあ、自分も以前まではやっていなかったので人のこと言えないのだけれど。


タスク可視化されていない

何をやっているのかわからん上にダマで変更加えてmasterにマージちゃうしかも変更しているのはモデル。もちろんテストはしないぜ。masterからブランチ切って自分作業に取り掛かってみると、知らない変更が加えられている。影響範囲なにそれ美味しいの?状態なため、変更に伴って他の部分/モジュールにはバグまくりテストコードコケまくりエラーまくり


これを誰がやっているかと言うと、上司にあたる人間がやっている。ちゃんと技術的な知識も持っているしコードもちゃんと書ける。自分よりも。なので余計にタチが悪い。一人で開発するんならそれでいいのかもしれないけど。ちなみにバックエンドエンジニアはその上司自分だけ。

働き始めて2年も経たないペーペーだし、年も離れているし、どういうアプローチをすればいいかからないんだよね。職場文化(?)を変えるのはそれなりの労力がいるし、とっとと転職して自分環境を変えた方がいいかもな、と思っているけど、如何せん地方なので、あんまり職がない。

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-10-19

BASIC!のプログラミング教育適応性について

題:BASIC!のプログラミング教育適応性について

副題:Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

少し考えてみたのでまとめとして投稿します。

01.はじめに

この文章は、Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

ついて記載しています

02.BASICとは

BASICプログラム初心者向け言語として1960年代に発表された古い言語です。

極めて簡単文法インタープリターによる即時実行や1970~80年代パソコン

無償で搭載されていたこから沢山の人に利用されていました。

しかし、簡単ゆえの機能の少なさと即時実行方式のための性能の低さやその後の

優れたプログラム言語発表によりBASICの利用は著しく低下しています

03.BASIC!とは

BASIC!はアンドロイドタブレットスマートフォン上で動くアプリです。

Google playからインストール可能無料で利用できます

BASIC!

https://play.google.com/store/apps/details?id=com.rfo.basic&hl=ja

BASIC文法踏襲していますが、Android向けに大幅に命令拡張されており、

GPS等の各種センサー情報取得やSQLiteデータベース機能WEBVIEWを利用

したHTMLCSSJS表示・実行など約500程度の命令群で構成されています

無料広告なしのアプリインストールするだけでこれらの機能が利用可能

インタープリターなのですぐに実行することもできます

04.BASIC!でプログラミング教育を行うメリット

メリットについては以下があげられます

a.BASICプログラミング知識を持つ人は以外と多い

 過去の栄光というかBASIC自体は広く利用された時期が過去存在パソコン

 だけでなくポケコンゲーム機等でも利用できました。

 BASIC!は基本はBASIC拡張であり文法変数の取り扱いにおおきな違いは

 ありません。

 その当時、少しであってもBASICを触った人は多いのでメンターとしての

 再教育は容易だと考えます

b.HTML,JS,CSS勉強継続してできる

 BASIC!は手続き型と呼ばれる非オブジェクト指向言語であり最新の言語

 とは異なっています

 BASIC!のネイティブ命令群だけだと他の言語へのスムーズな移行は難しい

 かもしれません。

 しかし、BASIC!にはHTML5アプリのようにBASIC!自体webViewでHTML,JS,CSS

 を動かすことができます。(HTMLモード

 HTML,JS,CSS現在Webの標準であり、進化を続けています

 特にjavascriptオブジェクト指向言語進化採用される領域フロント

 エンドからバックエンドまで広がっています

 

 BASIC!自体webViewは他のAndroidアプリ同様、chromiumベースAndroid

 システムWebviewの更新により常に最新化されています

 HTMLモードではjQuery,Angular,ReactなどのJSライブラリも利用できます

 最初BASIC!ネイティブプログラムHTMLモードJSを利用したプログラム

 とSTEPを踏んだ学習可能だと思います

c.インストール環境設定が容易

 前述の通りアプリインストールするだけで利用できます

 追加の課金プラグインなどは不要です。

 またAndroid2.3以降でインストール可能です。

 但しAndroid5.0あたりからAndroidシステムWebviewが導入されているので

 Android5.0以降の端末を選択する方が無難です。

 インストール後、環境設定をする必要もありません。

 端末のルート化も不要です。

d.Androidデバイス等が安価

 安いタブレットであれば1万円程度で新品が買えます中古スマホであれば

 更に安価です。

 またプログラムを作るのでキーボードもあった方がいいと思います

 キーボードも2~3千円程度で安価です。

 もちろんソフトウェアキーボードフリック入力など)でもプログラム

 作れます

 パソコンよりもはるか安価プログラミング教育が実現可能です。

e.子供Androidデバイスに慣れている

 iPhoneの登場以来現在の子供たちはタッチパネルAndroidデバイス

 慣れています

 通常のノートパソコンに比べ違和感は少ないと思います

 また教える大人側も日頃パソコンよりスマホを触る人は多いと思います

 教える側の負担も小さいのではないかと考えています

f.可搬性が高い

 ここで述べる可搬性とは別のデバイスで同じプログラムを動かす場合

 容易さの事です。

 BASIC!はインタープリタなのでソースファイルのみを別のデバイス

 SDカード経由等でコピーすれば基本的には動作します。

 仮にHTMLモード場合は併せてHTML,JS,CSSコピーするだけです。

 別のデバイスにはBASIC!さえインストールされていれば動きます

 BASIC!独自プラグイン拡張モジュールなどは特にありません。

05.BASIC!でプログラミング教育を行うデメリット

メリットだけでなくデメリットもあります。以下の通りです。 

a.性能上の問題

 BASIC!の実体Javaで出来ています。すなわちJavaよりは性能は悪い

 ことになります

 実際、大量の繰り返しや大量の文字列を扱うプログラムは性能が出ないので

 処理に時間がかかります

 Androidスマホタブレット自体パソコン演算能力には劣ります

 大量の実験データ演算するような教育には向いていません。

 但し、プログラミング教育には大きな障害にならないと思います

b.BASIC!自体の仕組みの問題

 BASIC!はプログラムを作るアプリである以上当然文法エラーを実行時に

 表示する仕組みになっています

 ただ一部エラーチェックが甘い部分もあり本来エラーとすべきところを

 そのまま実行する場合もあり想定外の結果となる可能性もあります

 次にエディタは単なるテキストエディタと同等の機能しかなく最近

 エディタにあるようなシンタクスハイライト入力補完といった機能

 ありません。

 ただ比較シンプルプログラムを作る教育では大きな影響は無いと

 考えています

c.一部機能に制約がある

 前述の通りHTMLモードではJSが動かせます。ただし制約があります

 JSローカルモードで実行されるという事です。

 非同期通信などを行おうする場合JSが実行時エラーになる可能性が

 あります

 またデータベース機能であるSQLiteへの操作についても文字型項目しか

 利用できない制約があります

 JSローカルモードのみなのは教育の事を考えると少し残念ですが

 それでも多くのフロントエンドJSは実行可能なので教育には

 使えるという理解でいます

d.参考となる文献がほぼない

 教育には教科書またはそれに準ずる書籍必要だと思います

 該当する書籍がないのが実情です。

 ただ1冊だけ日本語で書かれた電子書籍存在します。

 ■BASIC! ~ 分かりやすい教本で一から学べるコンピュータ言語 - AndroidSQUARE

 http://blog.livedoor.jp/an_square/archives/51887786.html

 BASIC!の文法自体は極めて簡単なのでどうにかなると思います

06.結論

上記の通り、メリット/デメリットを列挙してきました。

デメリットもあるものメリットの方が大きい印象です。

とくに教える側の負担が少ない点がメリットだと思います。 

 

2017-10-10

増田人達は開発で何の言語使ってんだろ

というか何言語使いの界隈がここに集まってるんだろう?

アプリバックエンドフロント??

日本語っていう答えはいらん

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん