「PHP」を含む日記 RSS

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

2017-09-16

株式会社はてな株主構成から見るはてな実態

今戯れに時価総額と持ち株比率から換算した資産表作った

近藤 淳也 66.33% 4482581400円 ○

(株)はてな 6.59% 445352200円

毛利 裕二 5.98% 404128400円

梅田 望夫 4.30% 290594000円

栗栖 義臣(社長) 2.61% 176383800円 ○

大西 康裕 1.97% 133132600円 ○

伊藤 直也 1.79% 120968200円 ○

田中 慎樹 1.41% 95287800円

田中 慎司 1.30% 87854000円 ○

小林 直樹 1.15% 77717000円

お金の額面はともかくの話なんだけど、

○をつけたのは、はてなコードを書いたことがあると"思われる人"。「名前 プログラミング」で検索して有意な結果が出た人に○つけた。各株主の詳細知りたい人は適当にググって

で、さら


はてな年収は524万円が平均年収です。(有価証券報告書調べ)

http://heikinnenshu.jp/joho/hatena.html

あると好ましい知識経験

スクリプト言語(主に Perl/PHP/Python/Ruby/JavaScript)によるアプリケーションライブラリ開発の経験

ScalaGoにおけるアプリケーションライブラリ開発の経験

iPhoneアプリ、もしくはAndroidアプリの開発経験

UNIX系OSRDBMS特に LinuxMySQL)についての基礎知識

オブジェクト指向プログラミングの基礎知識

コンピュータサイエンスアルゴリズムデータ構造分散技術自然言語処理技術機械学習データマイニング型理論)に関する基礎知識

ネットワーク技術HTTPDNSTCP/IPなど)についての基礎知識

大学卒/275,000円〜

http://hatenacorp.jp/recruit/fresh/application-engineer-entry

って、エンジニア待遇悪すぎじゃない?

この毛利 裕二という人の持ち株の資産新卒給料(計算だるかったか計算からボーナス抜いたけど、手取り分で考えたらボーナス分くらいは消えるだろう)で稼ぐとしたら122年かかるし、梅田 望夫という人は88年かかる。本当にこの人たちにはそれほどの価値(上にあげた新卒に求めるやたらと高いスペック)分の価値があるのか?いや、価値があると思ったから株をあてがったんだろうけど...

まぁなんていうか...、はてなのエンジニアのみなさんお疲れ様です...業務がんばってください

完全に外様の俺から言えるのは"エンジニアに"もっと給料たくさん払った方がいいんじゃないかということだけです

2017-09-14

同じプログラマでも違う

anond:20170913232648

うちは、WindowsServer + IIS + MySQL + PHP なので、 WIMP だなぁ。。

2017-09-13

LAMP環境って

今でも主要な開発環境なの?

この前某社の面接(中途採用)を受けて、結果的には落ちたわけだけど、

LAMP環境がなんとかってコメントとしてあり。

(落ちた直接の原因はLAMP環境経験ではないと思う)

Rails流行ってからPHPPerlはそれほど需要高くなくなったと思ってるし、

業務システムを開発している身としては、PostgreSQLのほうが使いやすイメージが強くて。

今でもWeb系開発ってLAMPが圧倒的なの??

2017-09-03

年収300万円稼ぐのが難しい

30代も中盤に差し掛かりスキルコミュ力も身につけてこなかった自分が悪いのはわかっている。

努力をしてこなかったツケが現状だろう。

正社員として働いていた時期もあったが続かなかった。派遣バイトで食いつなぐ日々。

自分社会不適合者なのだろう。だがまだ死にたくはない。

現在家賃税金含め総生活費が年間約150万。

生活費の倍ほど稼げば車は買えずとも原付くらいは維持できるだろうしTシャツをヨレヨレになるまで着なくても大丈夫になるだろうという金額が300万。

スキルと言えるかはわからないが仕事としてPHPJavaScriptを触っているので下手に畑違いに行くよりは同じ業界のほうが良いだろうと思っている。

希望としては自社サービス立ち上げ云々スライドみたいな会社で働いてみたいが技術力不足だろうしまた続かず辞めてしま可能性も高い。

今後どうやって稼いだらいいのかどんなアドバイスでもいいので教えて欲しい。

2017-08-26

Javaはクソという刷り込み

情報系の学科ではJavaは古い、ダメ、クソ。と言われる。

数値計算ではpython

Web開発ではPHPRubyjavascript

OSドライバカーネルを作るような人はC++

ナウい人はKotolinだC#Swiftだでアプリ開発をする。

そんな感じで、Java賞賛される場面を聞いたことがない。

Webアプリでも不具合があるのはJavaアプレットのものばかり。

からJavaダサいという刷り込みをされてしまってる。

そんな僕が来年から入る会社ではJavaを使うことになるらしい…不安だ。

https://anond.hatelabo.jp/20170826124852

流行ってるから何でも検索すれば出て来るし、コピペで何とかなるところがいいんじゃないの?

まあそれならPHPでいいんだが

2017-08-18

エロサイトアンテナサイト作ってみた

こんにちは

こちらに投稿するのは3回目ですかね。

過去に書いた記事

二次元系のエロサイトを作ったからいろいろ書いてみる 編集

https://anond.hatelabo.jp/20160225062051

自動更新エロサイトを作ったから自慢させて 編集

https://anond.hatelabo.jp/20150519124614

エロサイトばかり作ってます

懲りずにエロサイトアンテナサイトシステム含む)を作ったので投稿してみました。

作ったサイト

エロ萌えアンテナ
https://eromoe-antenna.link/

こりずにエロサイトです。

しかも今回はアンテナサイトという・・・

サイトを作ったきっかけとか

アンテナサイトは以前から作ってみたいとは思っていたのですが、何しろ情報が少ない。

既存無料システムなどは使い勝手が悪かったり、そもそも(私が思う)アンテナサイトの体をなしていなかったりと、不満がありました。

なら「私が思う」アンテナサイトを作ってみようと思った次第です。

また、1度作ればシステムを流用でき、昔はやった2chアンテナサイトなども簡単に作れるという打算もありました。

(今は下火ですがそれでも収益を上げることはできるので)

※このシステムは実は数年前に完成させたのですがバグだらけで一度頓挫したのを、1から作り直したものなのです。

使った技術

PHP

CSS

JavaScript

MySQL

これだけです。

かれた技術だけで作りました

仕様など

正直「アンテナサイト仕様」という情報はあまりネット上にも書籍などにも落ちていません。

なので私が思う仕様実装しました。

(有名サイトをみて「こうかな?」というのを整理しました。

ですかね。

あとはDBにいろいろ情報をぶち込んだので、後々の仕様変更にも柔軟に対応できるようにしました。

今回のアンテナサイトつくりで、だいぶSQL文の勉強になりました。

DB構造とかもWPなどのCMSを参考にリレーショナル?にしたとり、いろいろカスタマイズやすしました。

IN/OUT比率に応じてアクセスを返す処理についてはかなり悩み、これはみんな情報を出さないはずだなーと思いました。

秘伝のタレ的なものですよ・・・結局「こんなかんじかなー」というのを他サイト経験を元に推測して実装しました。

都度様子を見て変更するかもです。

こだわりの点など

お気に入り機能や、検索機能については結構実は力を入れています

検索機能は実は一番時間をかけています。世の開発者様はすごいですね。

https://eromoe-antenna.link/search.php?page=2&category=3

例えばカテゴリ3の2ページ目を表示、といった複数パラメータを持つ検索条件をどうやったらMySQLで取得するか、といったことや、

それをページャーにどうやって落とし込んでやれば良いのか、といったことがわかりませんでした。

普段WPを使っているので意識してなかったのですが、こういうところも自作システムの悩みどころですね。

あとはIN/OUTでの処理をするにあたり、一通りの情報DBに保存することで、後々いろいろ応用を利かせられるように設計しました。

その他には管理画面を設けることで、サイト更新やお知らせの投稿などを、WP並にとはいいませんが簡単に行えるようにしました。

デザインについて

完全自作です。

もともとPhotoshopで作っていたものがあったのですが、数年前に作ったものだったのでそれを基に開発を進めながら調整していきました。

スマフォサイト対応もしています

エロサイトっぽく?ピンクを使ってますが、正直もう少しやりようはあったかなーって思っています

システムさえできてしまえばデザインは後から変更し放題なので後々の課題ですね。

その他

作るのに1年以上かかってしまいましたが、何とか1システム完成させることができました。

おかげでだいぶ力がついたのではないかと思っています

今まではWPサイトを作ることが多かったので、1からシステムを作り上げて完成させるといった経験は実は皆無だったので、楽しかったです。

今は沢山のOSS無料ツールがあるので、自作する必要性も減ってきているかもしれませんが、実は自分がほしい機能ってピンポイントで無かったりすることも多いのではないでしょうか?

そういったときには是非皆さんも自作ツールを作ってみてはいかがでしょうか

以上、宣伝がてら、普段お世話になっている匿名ダイアリーにいろいろ書いてみました。

意見、ご感想などあればコメントとかくれるとうれしいです。

サイト登録申請もお待ちしています

https://eromoe-antenna.link/register/

2017-08-16

大規模webサービスって何の言語で作ればいいの

zozo townがヒットして、大改修を行うって話を聞いて思った。

そう言えばChat WorkもPHPで作ってて限界が来て移行したって聞いた。

FBだとかもそんな感じ。

最初から大ヒットするのが前提で作るとしたらPHPは良くないんだろうけど

なにで作るのが最適解なんだね

2017-08-02

憧れのlispを学びたい

元々phpから入ってruby on rails流行に乗って趣味rubyやってて一度プログラミングから離れてた

最近本の整理しててハッカー画家を読んでハマって全く読みこなせかったポール・グレアムon lispを手にとった

本当になんとなくの気持ちからlispを極めたいという気持ちになった

全く読みこなせかったのが悔しかったのもあるし、読みこなせなかったながらPGの今まで書いた記事を読めば読むほどこのlispというものがとてつもないものなんじゃないかと思うようになったのもある

lispについての概略を知れば知るほど自分の中の厨二をくすぐられる


・60年前のITの速度感で言えば古代プログラミング言語なのに最新のプログラミング言語lispの真似をしてるだけで追いついてない

マクロCLOSという機能がありそれを使いこなすと強力過ぎて他のプログラミング言語には戻ってこれないらしい

しかもそのマクロという機能は他のプログラミング言語には絶対に真似できないらしい

・その真似できない理由が()を多様するプログラミング文法に由来するから

・()を多用するがために他のプログラミング言語学習からするとかなり難しく見えるらしい

マクロというのはプログラムを作るためのプログラムらしい。元々AIプログラムを作ることを想定してたとか

こんな俺たち(?)の厨二心をくすぐるプログラミング言語ってあるか?絶対に無い

lispを使いこなして他のプログラマが1ヶ月で作るものを1日で作るとかマンガか何かみたいなことがしたい!絶対したい!!


で、俺が今やってることと言えばプログラミング言語というものが何をできるか調査するためにrubyで色々作っているところ

HTMLパーサーとかDBドライバlispで作るためにrubyのパーサーとかドライバコードを読んでると、自分が一体何をしてるのか分からなくなる

もちろんそれですぐに飯が食えるようになるのはrubyだ。給料もそれなりに良い。lisp求人を見たことは今まで一度もない

だけどこれもなんとなく遠回りでナンセンスな感じがしてる



直接lispを学ぶのが良いのか、急がば回れruby熟練するのが先か、どうなんだろうか

プログラマーの皆さん教えてください

2017-08-01

anond:20170801195616

すみませんJavaPHP を同列であるかのように並べないでください。

用途が全く異なりますので。

2017-07-15

自分なりのささやか復讐

おじさん、独り部署20年近く少しだけ特殊仕事してんのね。

若い頃は他部門の先輩に無茶で本来自分範疇外の仕事押し付けられて、

顎で使われて、そりゃ偉そうにされたもんだよ。

その人達は僕の都合や段取りなんかに聞く耳を持ってくれないんだよね。

おめーの都合なんか知らねーからとっととやれよ!もう夜の10時なんだけど。みたいな感じで。

そんなこんなで、無茶を聞いて頭を使って仕事効率化をはかって必死こいて頑張った結果、

偉そうにしていた先輩達よりも立場上は偉くなれたのね。

そこに到るまでの間に精神を病んだり体を壊したりもしたけど。

でだよ、こうなるとある程度は無茶な仕事拒否できる訳だ。

今まで聞かされてきた要求脳筋ならではの、「細かい事はどうでもいいから、俺の意を汲んで気合でやれ!」といった

内容だったから言うことを聞く必要は無いんだよね。そもそもその人達の部下じゃないし。

他人物事を頼むとき相手がどういった立場であれ、発注元は細かい情報を正確に伝える責任が生じる訳で、

その責任放棄して丸投げしてくるような人間の言うことなんて、こっちは知ったこっちゃないのよ。

すると不満が湧いてくるんだけど、それは僕に直接言ってくる訳じゃなくて、

もっと偉いひとから間接的に聞こえてくるのね。こんな風にあいつら不満を言ってるぞと。

かい不満の内容を聞くと、立場が変わってから偉そうになっただの、

僕だけ使っているソフトで楽をしているだの、ソフトがあれば俺でもできるのにだの。

いや、君らエクセルすらまともに使えないじゃない。

からね、おじさん、働き方改革を実行すべく、小学生の頃にN88-BASICしかやったことないのに、

仕事の合間にコツコツとプログラムWEB勉強をして社内にローカルサーバーを立ててシステムを組んだの。

WEBベースでアホでも理解できるUI、誰でも簡単保守管理できるやつ。

おじさん、普段からエクセル方眼紙を社内・社外から送りつけられてて、

エクセルのことが死ぬ程嫌いだからPHPで作った。

これがすごく便利で、自分が今まで投げられてきた仕事が誰でもワンアクション

終わらせるようになったんだ。当然システムの出力に応じたパソコン外での

作業は生じてくる訳だけど、それは誰でもできることだから、テメーら自分でやってね。

凄く便利になってよかったね。ざまあみやがれ。

これで時間に余裕ができたので、本来担当案件に集中して取り組むことができるし、

自分の退勤時間はほぼ定時になったし、有給もどんどん使ってやろうかと思うよ。

おじさん、娘が高校生になって手がかからなくなったから、

子育て期間に封印してた大好きなゲームを気の済むまで遊びたいんだ。

とりあえずSplatoon2ゼルダはやるし、ゲーミングPCをGTX1080で組んだから

STEAMで色々と買い漁るよ。

2017-07-10

Webアプリを作るときにどの言語/WAFで書くべきか

使ったことあるモノもないモノもごちゃまぜにして経験雰囲気で書いてる。

PHP

Laravelは結構好き。DSL過ぎず、それなりにフルスタック生産性もいい。

何よりLaravel本体ソースコードが読みやすいのがいい。

まともな日本語情報が少ないのは弱点だけど、気になったところは本体コードを読めばすぐに分かる。

最大の欠点PHPってことだ。他のLL言語に比べてPHP自体生産性は低い。セキュリティ面の不安も大きい。それに安心して後を任せられるようなPHPerは一握りしかいない。

Perl

Mojolicious結構好き。これもDSL過ぎず分かりやすい。CPAN豊富ライブラリ群もある。

Perlは可読性が悪いなんて言うけど、ちゃんとしたライブラリ普通に読みやすいよ。

最大の欠点Perlってことだ。長期的に開発者を集めることを考えたら茨の道だろ?

Python

今でこそ機械学習Pythonが人気になっているけど、Web系はまだまだマイナーだ。

Djangoプロジェクト/アプリケーションという構成単位の考え方が好きじゃない。理論的な利点は分かるけど、現実問題それが必要になるケースが浮かばん。

Django以外でフルスタックのWAFが出てくればいいんだけど。Tornadoはフルスタックじゃないのでちょっと違う。

Python3で安心して開発できるならアリだと思うけど今はどうなの?使いたいライブラリが3系に対応していないとかで躓きたくないよ。

あと単純に速度が遅いよね。いや書き方を気をつければマシにはなるんだけど、書き方を気をつけなければいけない時点でつらい。

Ruby

Railsは便利だ。周辺ライブラリの充実度もすごい。情報玉石混交だけどまともな情報もたくさんある。

ただあまりにもDSL過ぎる。Railsプログラミングではなく、一つの巨大なDSLだ。

Railsプログラマの何割が、少しでもいいかRails本体ソースコードを読んだことがあるのか。めっちゃ読みにくいんだけど。Rubyは可読性が高いなんて嘘だろう。Perlと一緒でちゃんとしたコードは読みやすいけどそれはプログラマ依存する話で、言語自体に可読性の高さはない。言語思想の通り書くのは楽しいよ。でも読むのがつらい。

Rails自体DSLみたいなもんなのに、RSpecやらRakeやら周辺ツールDSL意識高すぎる。

問題があった時にググらずにコード読んで解決できるRailsエンジニアはどれだけいるのか。情報量が多いからググれば解決すると答えるやつは、底辺PHPerと大差ないからな。

あとバージョンアップ追従するのが面倒過ぎる。でも放置したら負債になるし。意識高くRailsで開発したやつの大半はバージョンアップやらの保守に入る頃にはもうそプロジェクトはいないんだろ?だからそのつらさを知らないんだろ?

散々罵ったけど、このDSLを覚えれば生産性が高いのは事実だ。だから結局ついていく確率が高い。モテ男なんだよ結局こいつは。

Java

SIerさんに敬礼

Scala

Playが王道だけど最新バージョンになるほど情報が少ない。このあたりがRailsと違う。公式(英語)とか本体コードを読める人じゃないとつらい。

そもそもJava、というかJVM周りの知識がないと本番運用はつらいだろう。LL言語運用経験しかない人は特につらい。LL言語でいうhot deployみたいなことがしたい時のやりかた分かってる?

コンパイルの遅さに耐えて開発し、運用時のGC問題を乗り越え、黒魔術を味方につけてライブラリコードリーディングが出来るならいいんじゃないか

動作は早いし、言語のものは強力だ。

Scalaを好むプログラマ関数型やらDDDやら意識高い人が多い。別にScala自体にそれらは必須ではないけど、そこら辺を意識しないならJava8でいいんじゃないかとも思う。

Node.js

非同期処理で開発することの難しさに耐えられるの?

ベストプラクティスがなく、移り変わり激しいJS界隈に流されてオレオレで書いたコード保守する自信があるならいいんじゃない。俺はない。

Go

API単体ならともかく、画面も担う普通Webアプリを書くような言語じゃない。少なくとも今は。

正確に言うと書けないことはないけど、Webアプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットほとんどない。

ClojureとかElixirとか

運用実績ノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない

結論

完璧選択などない。

https://anond.hatelabo.jp/20170710120403

勉強会に出入りするような人間と、

PHPぐらいしかできない、やろうとしない」人間が交わる世界って無いよな

明らかに適正がないのにPGしてる人間なんてゴロゴロいるしな

テストケースすらかけないような奴ら、普通にいるし

派遣営業からは「ベテランPG」って触れ込みなんだけどな

2017-07-09

phpのいいところって

remoteでもlocalでも同じように動くという一点だけだと思うのよね。PGの単価が安いとかも有るけど。言語的には7.1からprivate const使えたり、まあ頑張ってる。

(※にも関わらず大本営が色々と改良しても、未だに新規案件で5.6とか持ち出す腐れ会社は滅びるべき)

なので、とにかくremoteでしか動かないコードってのやめてもらいたいんだよなあ。

Debuggerさえ使えるなら、magentoみたいなとんでもない糞コードの山(*1)であっても、コアコードを弄りまくったec-cube(特に2.x)であろうとも、縄文時代か?これ?みたいなオレオレフレームワーク(201x年でもオレオレ使ってるバカ会社が有るんですよ!)であっても追いかけて修正するなり殺すなり出来る。

ところがコード読み書きしないできないインフラ屋なんかが出張ってきて、やれvarnishだーSphinxだー云々やられるとDebugger使えないか死ねる。や、それを採用した人間人類滅亡の時まで保守改修するならどうでもいいことなんだが。localにそれらを構築する?や、出来なくねえけどめんどくせえし。

1

まあmagentoはコードがクソってのは置いといてもDB設計が完全に腐ってるのでさもありなん。

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

https://anond.hatelabo.jp/20170706120144

PHPならJSCSSもincludeで1ファイル内に展開しちゃえばいんじゃね?

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

当方フリー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-27

学校の授業でプログラミングを教えるとしたら言語は何が良いのだろう

自分情報系の大学生

弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。

中学生の頃からパソコン大先生スクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。

ちなみに、試験は紙ベースで、手書きプログラミングをさせられる。つらい。

スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。

結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。

プログラミング学者である人は苦労して書き方を覚えていたように思う。

脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである

本来プログラミングは誰でも出来るはずである

今学期、PHPを書く授業とPythonを書く授業を履修してみた。

PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストコードを動かす気力のない自分にとっては最高の授業だ。

Pythonは、MeCabなどで形態素解析構文解析をする授業で、サンプルコード自分で考えてカスタマイズして毎回レポートで提出する。

Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。

やはり、スクリプト言語楽しい

書いたらすぐに目に見える成果が出るところが大きい。

自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。

そう思っていた矢先に事件が起こった。

最近研究室に入ったところ先生が手当たり次第Javaを教え始めたのである

せめてJavaScriptでいいかスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。

それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。

コンパイル言語も悪くはないと思い始めた。

ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。

絶対にツマラナイだろう。

自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。

こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。

お願いだからプログラミングを教えるのならツマラナイ授業をしないで欲しい。

生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。

別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。

自分は、分かりやすくて直感的なRubyというプログラミング言語学校の授業で採用されるべき言語に間違いないと思う。

別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。

CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。

スクリプト言語を教えた後に、コンパイル言語オブジェクト指向概念を教えていくのがいいのではないだろうか。

これは、あくまでもたった1人の大学生意見しか過ぎない。

みんなの意見を知りたい。

2017-06-17

同じく今の増田の年齢にもよる

https://anond.hatelabo.jp/20170617024529

あんまり人生相談の答えに関係ないけど

HTMLファイルをよくわからんCMSテンプレートとして当て込むだけのことを長年やってきたおじさん」

これに近い経歴のお方を、派遣会社からの紹介でお断りしたことが多々...

だって急募即戦力ってオーダーに、PHPできるJSできるJavaもやってました!って触れ込みだったのに、CMS触ってたのがメインの経歴で、質疑応答曖昧に「本読めばできます」「頑張ります」と言われても。

まあこの場合は単なるミスマッチしかないし、こういう作業が今後なくなるかはよくわかんない。

つっても全く同じ経歴の人が2人いたとしていざ面接ってなったら、年齢とか、真面目そうとか、話が合いそうとか、本人の資質と全く関係ないところで選ばれてしまうと思うんだよね。

だってCMSやってただけじゃプログラマ資質わかんないもん。

逆にWordpressメインでやってきましたが、脆弱性回避のためにこんな事をやってきました!プラグイン同士相性悪いのをこう対処しました!みたいなほうが期待できそう。

今後プログラマとして飯喰ってくつもりだったら、先のトラバでも言われてたとおり家で趣味プログラムとかしたほうがいい。

正直、CMS展開はプログラマ仕事じゃないと自分は思ってる。

もっとも書いてある経歴から察すると、ディレクターの方向に舵切ってみるのもいいんじゃない

CMSや、PHPある程度でも判るWebディレクターって重宝するよ。プログラマからすると鬱陶しいけど。

それでも最終的に言うとしたらタイトルの内容になります

こんな感じ?

Web系に入社して3年目 人生相談

うちの会社Web系なんだから当然っちゃ当然なんだけど、案件の8割くらいはCMS案件なのよね。

それもWordPress脆弱性出しすぎとかで保守しにくいってことでもうちょいマイナーCMSが中心。

プログラマーとして入社してから今まで、デザイナーが渡してきたHTMLファイルCMSテンプレートとして構築する、

っていう作業社会人生活の半分以上を占めていて、業務としてはPHP簡単プログラミングすらあんまり経験ない気がする。

CMSテンプレートもif文とかループとかあるからこれもプログラミングといえばプログラミングなんだけど、

Web系っていうともっとPythonとかNode.jsとかVueみたいなキャピキャピした技術に触れるもんだと思ってたよ。

給料は安いけど割りかし残業も少なくて何かとヌル会社から今のところやめるつもりは特にないんだけど、

ディレクターとの調整とかExcel方眼紙仕様書(多分一般的SEが作るのよりはかなり簡潔なもの、勿論UMLとかはない)書いたり見積もりしたり操作マニュアル書いたりっていう経験はあっても

下流工程を生きるプログラマーとして例えば5年後10年後、技術的なキャリアとして「HTMLファイルをよくわからんCMSテンプレートとして当て込むだけのことを長年やってきたおじさん」

誕生したとして、果たして生きていけるのか心配になってきた。

僕は生きていけるのでしょうか。転職した方がいいんでしょうか。教えてください。

2017-06-09

http://anond.hatelabo.jp/20170608235436

perl流行ってた時期を知らんのか。

この増田はてな最初perlで、多分今でもperlのままだと思うぞ。

perlよりいいものが出てきたから今から始めるならperlという選択肢はないだけで、RubyPHPが使い物になるようになる前のゼロ年代Webサービスを作るのにperl以外の選択肢はほぼなかったんだが。

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