「フロントエンド」を含む日記 RSS

はてなキーワード: フロントエンドとは

2017-07-21

https://anond.hatelabo.jp/20170721231601

わからんフロントエンドエンジニアとかの下り特にわからん、アンタが妙なコンプレックス持ってるだけだと思う。単純に自分役割をきちんと示してるだけだと思う。

インフラエンジニアに対する理解力の低さから、まぁ、IT全般に弱いんだろうな、頭弱いんだろうなというのは判った。ネットワーク設計とかルータの設定が「サーバ屋」に含まれてると思っている、と言い切るなら、まぁキチガイ一種か、本当に頭弱くて理解力が低いだけだろうな。

サーバだけ出来ればインフラエンジニア出来ると思ったら大間違いなんだよ。だからサーバ屋じゃなくインフラエンジニアなんだよ。ネットワーク設計だって技術力が必要な立派な仕事だよ。ルータだけで数千台あるようなネットワークを構築するのは誰か、インフラエンジニアだよ。それが技術じゃない、サーバ技術のおまけっていうなら、あんたがIT業界去った方が業界のためになるっていう理屈、判るだろう。

総じて、あんたが相手仕事をきちんと理解出来ない事からの誤解だろうと思うんだけどね。

Web系、フロントエンド界隈エンジニアの息苦しさ

性欲かっこ悪い、風俗なんてもっての他、モテないアピール必要

業務時間外は常に勉強機械学習数学四苦八苦

できれば有名OSSコミッタQiitaツイッター情報発信

週末余裕があれば勉強会に参加、できれば爽やかな笑顔自虐ギャグで登壇登壇登壇、

でも最新のアニメゲーム漫画もチェックしてオタク趣味の余裕あるとこもアピール

開発はアジャイルスクラムDDDでと意識高い

マネジメント論とキャリアパス論もいっちょまえに語って大人アピール

ええーい、Web系のカタカナ世界は息苦しいんじゃいボケ

そりゃ隠れて風俗行ってドハマリしまわ!

わしら人間なんじゃ!

エンジニアって名前バーチャル動物じゃないんや!

2017-07-11

高校大学生にいいたい、ネットプログラマー愚痴っても真に受けるな

WEB始まりすぎだし、アプリゲーム始まりすぎなんですけどって話

SIは知らないし、アプリは聞いた話だからあれだけど


WEBに関してはruby/railsとかは900万超えの求人出しても来てくれないくらいには好調です

HTML/CSS/JS/Railsができて仕事ないとか言ってる人いたら教えてほしいくらいだよ

俺の会社他にアプリ部門があるんだけどもっと人が足りないって愚痴ってるしこのままだと1000万行くかもしれない、うらやましいくらいの話だ


まぁ結局はてなも2chもそうなんだけど、ネット愚痴ってるやつって仕事できない無能が8割か、転職怖い昇給交渉怖いって動こうとしないビビリのクズ

それか若者つぶそうとして楽しんでるやつか、なにかしらの病気なので相手にしないほうがいい


進化が早すぎてついていくのがつらいよーってやつの話にも聞かないほうがいい

HTMLCSSにかぎっていえば、そんな変わったことな

追加された機能ゴリゴリ生かさなければいけないなんてシーン俺は知らない

まぁ大きく変わったのはFLASHが廃れて」、HTML5/JS代替しなければいけなかったことくらいだけど

べつにそれに関しても大した話じゃない。ゆっくり以降していった話

フロントエンドはつらいなんて話をよくしてる連中いるけど、ただの馬鹿ファッションで乗って、つらさを自慢しあってるだけ

あいつらがやってることの9割は必要ないことで苦労してると思うわ

gulp/grantなんかのタスクランナーとかする必要ないのにして変化が激しいとか愚痴ってる意味の分からない

anguler/ract/vueあたりもな

SPAなんて特殊ものをこれから来る必須技術みたいにさわいで技術飛びついて変化が激しいって騒いでスターもらいたがってるだけ

結局ブログ承認欲求みたすための苦労自慢でリスカ女と変わらないので相手にする必要なし


railsは変化が速いのでは?なんて話も真に受けるな

しかに3くらいまでは俺自身が慣れてなかったからつらかったといえばつらかったが、その程度の変化ほかの業界でもいくらでもある

なによりネットドキュメントが大量にある、はっきり言ってほかの産業にくらべて勉強が楽なくらいだ(ググるときに注意が必要だけど、情報の鮮度とか正確性とか)

railsフレームワークが1強なので迷わなくていいし仲間も多いから、かりに変化がおこっても、頭のいい人がドキュメント残してくれるし、勉強で困ったことなんかほぼない

5.1でjquery依存をなくすとか、CoffeeScript廃止とか、yarn採用も困らなかった


もう一度言う

プログラマーリスカ自慢に気を付けよう

あいつら無能かただのかまってちゃんから

プログラマーになりたいと思ってる君、情報工学部(コンピューターサイエンスやる学部ね)行こうね、私は大学電気科に言ったんだけどいまだに後悔してる

あのときプログラマー未来を信じれなかったからね

プログラマーなんかIT土方だしとか言われてて電気機械のほうがいいといわれて私は電気を選んだんだよ

組み込みPGなら電気電子でもいいかもしれない。オープンになりづらい職業からたいへんだろうなって思うけど。

2017-07-09

wordpressさいこーといってる人へ

wordpress最盛期。あの案件もこの案件WordPressを使って、プラグインしまjqueryしまし脂マシマシな納品が星の数ほど生まれていく。「プラグインが最新バージョン対応しないので、本体バージョンアップができません」といってセキュリティホールだらけのwordpress放置される。アホかと、バカかと。

フロントエンドhtml,css,javascriptでつくるものだよ。expressをみて「javascriptバックエンド書くの?気持ち悪い」っていってただろ。それと同じだ。いつまでphpフロントエンド書くつもりだよ。phpで動的生成し続けるからいつまでもwp headでwordpressサイトってバレてアタック受けるんだよ。とりあえずurlの末尾にwp-adminってつけて確認されるんだよ。

分離しろ、分離。wordpress管理画面が悪いとはいわない。あいはいいやつだ。けど、wordpressフロント書く必要はない。wordpressrest apiだしただろ。更新wordpressでやって、その情報apiで取得してきたらいいんだ、それでいい。

wordpressテーマをつくるのがキャッチだった頃からもう6年はたった。6年前といえば、Windows 7使ってた頃だよ。ヒカリエまだできてない。そんな頃のやり方つかって「これがスタンダードです」とかいってクライアントをだまくらかして楽しいか。さっさと2017年に追いつけよ。

2017-07-06

無知無理解プロジェクトが殺されそうだ

当方フリーIT 技術者。ある Web ベースシステムを開発しているのだが、プロジェクトマネージャーリーダーをはじめとするメンバー無知無理解のおかげで作業が進まずに困っています

ブラウザーキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。

登場人物

私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。

A 社内のチームメンバーは以下のとおり。

さて、今開発しているシステム(以下システム P)はもともとスタンドアローン運用する形態だったが、最近クラウドバージョン提供も始まり現在スタンドアローンバージョンクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバー管理や、私や W さんが作った部分のテスト担当している。

問題発覚

クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードアップデートすると、ブラウザーキャッシュが効いていて表示がおかしくなるというのだ。

プログラマー以外の 4 人は実は Web システム案件は初めてで、ブラウザーキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーキャッシュクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミークエリ文字列をつければよい。アップデートのたびに数字を変える。これは一般的採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。

これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。

前回リリースから変更のあったファイルの洗い出しを命じられる

X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルリストを出してほしい」と言われる。変更のないリソースにはクエリ文字列をつけたくないらしい。

内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコード確認し、この一覧表に載っているファイルにはクエリ文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイル対象にしたほうが作るほうもテストするほうも楽です」と伝えた。

問題発生箇所の調査を命じられる

6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラスID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。

私は「ブラウザーキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュ問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。

ブラウザーキャッシュの仕組みを基本から説明する

プログラマー 4 氏の知識底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーキャッシュの仕組みを解説する文書投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまりかいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。

キャッシュとは

キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります

ウェブブラウザーにおけるキャッシュ一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイルJavaScript ファイル画像ファイルなど)に対して適用されます

キャッシュが作られるタイミング

ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。

キャッシュが破棄されるタイミング

キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルキャッシュが同じ期間だけ存在するかどうかも分かりません。

キャッシュユーザーブラウザー操作で明示的に削除(クリアー)することはできますが、 サーバーからクライアント(ブラウザー)のキャッシュクリアーすることはできません。

ウェブアプリケーションキャッシュ対策

ウェブアプリケーションアップデートした際、クライアントキャッシュ無効にするために、以下の手法がよく使われます

link rel="stylesheet" type="text/css" href="style.css" >
< script type='text/javascript' src='script.js' >< /script >
< img src="picture.jpg" alt="" width="640" height="480" >

このような外部リソース読み込みについて、ファイル名の後ろにクエリ文字列を追加します。

link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >
< script type="text/javascript" src="script.js?v=2.4.0" >< /script >
< img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" >

スクリプトでない静的ファイルクエリ文字列を付加しても、読み込まれファイルは同じです。つまりstyle.cssstyle.css?v=2.4.0 は同じ style.css というファイルを指します。

ブラウザーが style.cssキャッシュしている状態で、この行を読み込んだとします。

link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" >

ブラウザーは「style.css?v=2.4.0 というファイルキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれスタイルシート更新されます

この HTML をまた読み込んだ時は、「style.css?v=2.4.0 というファイルキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。

ウェブアプリケーションバージョン 2.5.0 にアップデートする時には、「?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。

link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" >
< script type="text/javascript" src="script.js?v=2.5.0" >< /script >
< img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" >

同様の仕組みで、2.4.0 時代キャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれキャッシュ問題は起こりません。

この手法は、キャッシュ問題解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます

上記に長々と書いた内容を踏まえ、今回の問題についてご説明します。

「暫定対応」の指示が出る

日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(< div style="..." >)で指定すればよい」と結論づけていた。

報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。

この報告書を元に、X さんから「この行とこの行にインラインスタイル指定してください。これで暫定対応します」と指示が出た。

私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境たまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業完了した。Gitコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。

しばらくすると X さんから「うまく表示されていますOK です」と報告があった。

その日のうちに問題再発

夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScriptキャッシュですね」。

聞けば、Y さんは「キャッシュスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタン有効だったとも。

私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。

Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。

私は繰り返し、ブラウザーキャッシュ環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。

「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者意見を聞いてください」

対応が先送りになる

この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。

聞けば、リリースを急いでいるのは特定顧客要望によるものらしい。その顧客スタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーキャッシュを消してくればいいとのこと。

リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。

レビュー開催

そして今日夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。

X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。

ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態対応策を一生懸命協議していたのですな。

レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者説明してもらったって、信じないんだったら意味がないのにねえ。

追記

文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。

https://anond.hatelabo.jp/20170706122924

2017-06-20

Reactを今更やってみた

Reactクソって言い続けて来たけど、新規顧客からReactじゃないとやらんとか言われて失注したので今更ながらやってみた。

1週間使ったけど、良いねこれ。VueJSでReactiveなフロントエンド開発はやったので意外とすんなり理解できた。

これを機に自分のFrontendのスキルセットを、ES6、Webpack、Flux、React-Route、Reactに刷新した。

今までは、Gulp、VueJS、Browserify、BackboneJS、jQuery。。2014年位のスタンダードだよなぁ。

何が良いとか具体的に書く時間が無いけど、直感的に良いなと思えるようになったわ。

やっぱ、やらずして頭から否定よくないわ。

2017-06-17

21世紀架空請求サイトウォッチする

まさか登録完了しました』からの『誤動作によるご登録につきましては、メール電話にてご連絡の上退会申請キャンセルを行ってください。』

なんて古典的なページを、21世紀にもなってお目にかかるとは思わなかった。

ページをスクロールしていくと『ご利用料金』があり、税別で数十万の値が記載されている。

お客様ID』『ご登録完了日時』はページをリロードしてもcookieを削除してもそのままであった。

Torブラウザー経由でアクセスすると『お客様ID』『ご登録完了日時』が変化したため、

おそらくアクセスIPに紐づけて日時等を保持しているのではないかと予想する。

『お支払期限』は三日後に設定されていた。

その下には『利用規約』『注意事項』が並ぶ。『有料サービスにつき必読』ともある。やさしい。

流し読みしてみると、『再生ボタン利用規約認証としその先に進みますと当該内容の確認及び承諾をしたものとみなされます。』という。

サービス機能認証を併せるというのは興味深い発想である

『本サービスアダルトに類される画像映像の表示、配信を行っているため、勤務先や第三者の所有しているパソコンからの利用を禁止する。』ともある。

ユーザー不祥事を先回りして戒めてくれるとは、すばらしい。

『会員の都合による一方的キャンセルは受けられないものとする。本サービスクーリングオフ適応対象外である。』という。

そのように言えばそうなるのだとは存じ上げなかった。

ここまで鼻で笑っているユーザーを想定してか、『悪質ユーザーへの対処の流れ』という記載がある。

『[1.書類送付](滞納1日目)』『[2.回収代行業者委託](滞納3日目)』『[3.少額訴訟(全額請求)]』というように、法的な手段も辞さない構えをアピールしてくる。

但し書きの書式が3つめだけ異なるのが気になるが、些細な問題であろう。

しかし、このような対処方法お客様社会的地位社会的信用を傷つけてしまますので、理由の如何によっては滞納料金の免除等できる限りのご対応はさせて頂きたいと思っております。』

なるほど、とても慈悲深い対応だ。さぞ良い人なのだろう。

さらに続けて著作権についての講義が始まる。

違法ダウンロードはれっきとした【犯罪】です。』

動画視聴サイトの会員登録という体のサイト違法ダウンロードによる著作権侵害の話を持ち出すのはよくわからないが、

要するにタダで見るのではなく金を払えということを言いたいのだろう。

『【そんなつもりはなかった】【何も知らなかった】【みんなやっているはず】そういう言葉法律では一切通用致しません。』と記し、

両手に手錠をつけた画像を大きく貼り付けて文章の締めとしている。

私も三日後にはこうなってしまうのだろうか。

HTMLソースを眺める。『<!-- sample -->』『<style>』『<span style=』など、手作り感のある牧歌的コードであった。

多数のコードコメントアウトされている箇所があり、おそらく画面遷移によるページの差分コピペで使いまわして修正しているのではないかと予想する。

読み込んでいるjQueryバージョンは1.9.0であった。なお、現時点におけるjQueryの最新バージョンは3.2.1である

URL拡張子をそのまま信じるのであれば、使用言語PHP

404ページ出力をそのまま信じるのであれば、使用WebサーバーApache

極めてオーソドックス構成であり、技術の習熟や人員招集において比較的苦労せずに済みそうである

ドメインwhois を眺める。

この架空請求サイトドメインは 2017-05-11T07:24:01Z に登録されたらしい。わりと最近の話である

申請者の情報は 『Privacy Protection Service INC』 なる企業のものになっていた。

privacyprotect.orgwhois 情報の代行を担うサービスらしい。勉強になった。

ドメインレジストラpublicdomainregistry.com で、 Abuse Reports よりフィッシングサイト等を通報できる体制になってる模様。

しかし、入力フォーム自身名前メールアドレスを入れる必要があるので面倒臭そうではある。

やはり、こういう架空請求サイト国外拠点にして取り組むらしい。

以上、『聖なる膣69』という架空請求サイトであった。

こんなものであっても、サーバーフロントエンド知識をそれなりに勉強した人間が関わっているはずで、彼/彼女人生はそれでよかったのだろうかと思いを馳せずにはいられない。

ちなみにサービス名でググると悪質業者架空請求について注意を呼び掛けるサイトがいろいろ出てくる。

そういう意味では、まだまだネットも捨てたもんじゃないように思えた。

2017-06-16

フロントエンドエンジニア

自分はい一般的にこう呼ばれる仕事をしてるが、正直他のエンジニアより明らかにレベルが低いと思う。

他の職種もやってきたので、如何にフロントエンドエンジニアたちがそうじゃないと言おうが、そうだと断言できる。

当人たちも薄々勘付いてると思うのだけど何故か認めようとしない。

どう考えても、html/css/jsなんて他の言語より簡単だろ

最近はreactとかangularとかあるし、es6だの、webpackだの、色々あるから難しいんだ、って意見がありそうだけど、いやそんなもん他の言語でもフレームワークビルドツールやまほどあるだろ

もっと他の職種に興味を持ったほうが、フロントエンドエンジニア未来が明るいと思うのだけど

2017-06-02

webデザイナーエンジニアへの道

ここ半年ぐらいずっとwebデザイナーになりたいと思って就活してるが、貯金とかもやばくなってきたので他の人に相談したいと思ってこの日記を書く事にした。

正確にはフロントエンドエンジニアになりたいのである

昨年の11月くらいに無職になってそこから1月から職業訓練行って3月末で終了して、そこから就活してるが、なかなか決まらん。

デザインとかはあまり得意ではないのでどちらかとエンジニアになりたいけどいきなりエンジニアとか無理だろうなと思って、デザイナー狙いながらやってる。

アルバイトとかにも募集してるんだけど作品見てもらってアウトー!!みたいな感じ。

その間にもプログラム勉強とかしながらやってるけど決まる気配もない。

保育園落ちた日本死ね!!」とは言わないが同じぐらいの気持ちである

現職でそういった職業についている人はどうやって業界に入ったのだろう?

教えてください。

2017-05-28

http://anond.hatelabo.jp/20170528212301

サーバ側でもフロントエンドでもなんでもいいぞ。

とにかく何かを「完成」させろ。それをgithubに上げて、堂々と面接受けろ。

何も恥ずかしいことはない。そのgithubが業績だ。

今どこも人足りないから、すぐに採用される。2秒で。

あと少しだ。あきらめるな。

2017-05-21

http://anond.hatelabo.jp/20170521170846

フロントエンド側のガチャ確率は、あくまでも体感確率であって

実際に設定されている確率とは違っても問題無いのです。


フロントが7で、サーバサイドが3.5なら、残りの3.5はどこに?

と思うかと思いますが、これは運営裁量で上得意客に配ったり、

特定イベント時期だけ、確率10にしたりと調整するためのマージンなんです。

スマホゲーのガチャ確率の表設定と裏設定の件

渋谷にある大手スマホアプリゲーム作ってる会社で働いているのだが

フロントエンド側のガチャ確率の内容と

サーバーサイド側のガチャ確率の設定が

違うのが業界の当たり前っていわれたんだけど、本当か?

レアが7%とフロントエンド側に書いてあってもサーバサイド側は3.5%とか普通に設定していて草

これって詐欺じゃないの?

東証一部に上場しているけど、これ絶対アウトだよね。

2017-05-19

二年前に受けた某企業技術研修について

ふと思い立ったので書いてみる。二年前、新卒として某企業技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaフロントエンドのAngularやReactをどう連携させるか、もしかして自作フレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。

詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。

ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチプロダクトを作れということだった。意味が分からなかった。

評価するためには十分量のコード必要ということは理解していた。過去研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか?

Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaプロダクトを理解するのならそれこそフルスクラッチ要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。

Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方からフレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画修正し、適当プロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。

今年の新人も同様のカリキュラムだという。しかもまだWindowsフレームワークは一切使えない。エクセルワイヤーフレームを書けという。SIじゃないか大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身勉強し、論文技術書を読み、週末に自分プロダクトを作る習慣をつけておかないといけない。自衛しないといけない。

そんな不幸な人たちがいればいいのにと思った。

2017-05-14

http://anond.hatelabo.jp/20170513175715

JavaScriptフロントエンドか、JavaAndroidあたりが需要が多くて潜り込むチャンスが多いんでない?

ただ、無職のままでってのは厳しいな。そんなにすぐには習得できないしな。

中途である以上、ある程度の実力は期待されるだろ。

2017-05-09

JavaScript簡単SPAフレームワークってありますか?

勉強が不得意な職業プログラマですが、WindowsアプリSPAに作り替えることになりそう。

プロジェクトメンバー積極的技術習得するような人はいないので、簡単フレームワークを探しています

↑に近いようなフレームワークありませんか?

2017-05-08

http://anond.hatelabo.jp/20170508004959

megumin1の「フロントエンド界のTehu」というブコメは中々良かった。

そしてうまく行けば潰し合ってくれるのかもな。

2017-05-06

結局Vue.jsが最強だった

Reactは大規模なフロントエンド開発なら良いかもしれないけど何もかも大げさすぎだし概念理解するのが大変

Angular2は最初覚えなきゃいけないことが,TypeScriptからまりES2015、依存モジュール多数と始めるのがまず大変

Knockoutは古いブラウザサポートしなきゃいけないとき以外は使わない

jQueryでのDom操作は増えてくると辛みがあるリアクティブに書くのは大変

Vue.js使うと覚えること少ないわ、リアクティブに動くわVirtualDomなんて意識しないで良いわで最高すぎる

たいていこれで良いんじゃないか

2017-05-04

http://anond.hatelabo.jp/20170504171337

あんまり詳しくない事務系の人間が言うんだが、

増田用途だとAccess使っても結局フロントエンドExcel使わんといかんような気がするので、おすすめしない。

といってExcelだと無用に重くなるというのはよくわかる。

ソートに関してはマクロとかで改良できると思うが、重くなる問題はどうしようもなかろう。

ハードウェアアップグレード対応するという姑息手段もあるが、Excelファイル肥大化していくだろうから問題を先送りにするだけという気もする。

きちんとしたデータベースSQL)の知識があれば解決できるのだと思うが、かなり敷居が高い

似たようなことでずい分昔に悩んだことがあるので、思ったことだけ書いた。参考にはならんな。

しかあのときは、中途半端マクロ書いてごまかして、そのあとで会社辞めたんだったわ。

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