  |
はてなキーワード: PHPとは
（株）はてな 6.59% 445352200円
毛利 裕二 5.98% 404128400円
梅田 望夫 4.30% 290594000円
伊藤 直也 1.79% 120968200円 ○
田中 慎司 1.30% 87854000円 ○
小林 直樹 1.15% 77717000円
お金の額面はともかくの話なんだけど、
○をつけたのは、はてなのコードを書いたことがあると"思われる人"。「名前 プログラミング」で検索して有意な結果が出た人に○つけた。各株主の詳細知りたい人は適当にググって
で、さらに
はてなの年収は524万円が平均年収です。（有価証券報告書調べ）
http://heikinnenshu.jp/joho/hatena.html
スクリプト言語（主に Perl/PHP/Python/Ruby/JavaScript）によるアプリケーション、ライブラリ開発の経験
ScalaやGoにおけるアプリケーション、ライブラリ開発の経験
iPhoneアプリ、もしくはAndroidアプリの開発経験
UNIX系OS、RDBMS （特に Linux、MySQL）についての基礎知識
コンピュータサイエンス（アルゴリズムとデータ構造、分散技術、自然言語処理技術、機械学習、データマイニング、型理論）に関する基礎知識
ネットワーク技術（HTTP、DNS、TCP/IPなど）についての基礎知識
大学卒／275,000円〜
http://hatenacorp.jp/recruit/fresh/application-engineer-entry
この毛利 裕二という人の持ち株の資産を新卒の給料(計算だるかったから計算からボーナス抜いたけど、手取り分で考えたらボーナス分くらいは消えるだろう)で稼ぐとしたら122年かかるし、梅田 望夫という人は88年かかる。本当にこの人たちにはそれほどの価値(上にあげた新卒に求めるやたらと高いスペック)分の価値があるのか？いや、価値があると思ったから株をあてがったんだろうけど...
まぁなんていうか...、はてなのエンジニアのみなさんお疲れ様です...業務がんばってください
30代も中盤に差し掛かりスキルもコミュ力も身につけてこなかった自分が悪いのはわかっている。
努力をしてこなかったツケが現状だろう。
正社員として働いていた時期もあったが続かなかった。派遣やバイトで食いつなぐ日々。
生活費の倍ほど稼げば車は買えずとも原付くらいは維持できるだろうしTシャツをヨレヨレになるまで着なくても大丈夫になるだろうという金額が300万。
スキルと言えるかはわからないが仕事としてPHPやJavaScriptを触っているので下手に畑違いに行くよりは同じ業界のほうが良いだろうと思っている。
希望としては自社サービス立ち上げ云々スライドみたいな会社で働いてみたいが技術力不足だろうしまた続かず辞めてしまう可能性も高い。
今後どうやって稼いだらいいのかどんなアドバイスでもいいので教えて欲しい。
https://anond.hatelabo.jp/20160225062051
https://anond.hatelabo.jp/20150519124614
懲りずにエロサイトのアンテナサイト（システム含む）を作ったので投稿してみました。
こりずにエロサイトです。
アンテナサイトは以前から作ってみたいとは思っていたのですが、何しろ情報が少ない。
既存の無料システムなどは使い勝手が悪かったり、そもそも(私が思う)アンテナサイトの体をなしていなかったりと、不満がありました。
なら「私が思う」アンテナサイトを作ってみようと思った次第です。
また、1度作ればシステムを流用でき、昔はやった2chアンテナサイトなども簡単に作れるという打算もありました。
（今は下火ですがそれでも収益を上げることはできるので）
※このシステムは実は数年前に完成させたのですがバグだらけで一度頓挫したのを、1から作り直したものなのです。
これだけです。
正直「アンテナサイトの仕様」という情報はあまりネット上にも書籍などにも落ちていません。
ですかね。
あとは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や無料ツールがあるので、自作する必要性も減ってきているかもしれませんが、実は自分がほしい機能ってピンポイントで無かったりすることも多いのではないでしょうか？
そういったときには是非皆さんも自作ツールを作ってみてはいかがでしょうか
以上、宣伝がてら、普段お世話になっている匿名ダイアリーにいろいろ書いてみました。
元々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を熟練するのが先か、どうなんだろうか
プログラマーの皆さん教えてください
おじさん、独り部署で20年近く少しだけ特殊な仕事してんのね。
若い頃は他部門の先輩に無茶で本来自分の範疇外の仕事を押し付けられて、
顎で使われて、そりゃ偉そうにされたもんだよ。
その人達は僕の都合や段取りなんかに聞く耳を持ってくれないんだよね。
おめーの都合なんか知らねーからとっととやれよ！もう夜の10時なんだけど。みたいな感じで。
そんなこんなで、無茶を聞いて頭を使って仕事の効率化をはかって必死こいて頑張った結果、
偉そうにしていた先輩達よりも立場上は偉くなれたのね。
そこに到るまでの間に精神を病んだり体を壊したりもしたけど。
今まで聞かされてきた要求が脳筋ならではの、「細かい事はどうでもいいから、俺の意を汲んで気合でやれ！」といった
内容だったから言うことを聞く必要は無いんだよね。そもそもその人達の部下じゃないし。
他人に物事を頼むときは相手がどういった立場であれ、発注元は細かい情報を正確に伝える責任が生じる訳で、
その責任を放棄して丸投げしてくるような人間の言うことなんて、こっちは知ったこっちゃないのよ。
すると不満が湧いてくるんだけど、それは僕に直接言ってくる訳じゃなくて、
もっと偉いひとから間接的に聞こえてくるのね。こんな風にあいつら不満を言ってるぞと。
細かい不満の内容を聞くと、立場が変わってから偉そうになっただの、
僕だけ使っているソフトで楽をしているだの、ソフトがあれば俺でもできるのにだの。
いや、君らエクセルすらまともに使えないじゃない。
だからね、おじさん、働き方改革を実行すべく、小学生の頃にN88-BASICしかやったことないのに、
仕事の合間にコツコツとプログラムとWEBの勉強をして社内にローカルサーバーを立ててシステムを組んだの。
WEBベースでアホでも理解できるUI、誰でも簡単に保守管理できるやつ。
おじさん、普段からエクセル方眼紙を社内・社外から送りつけられてて、
これがすごく便利で、自分が今まで投げられてきた仕事が誰でもワンアクションで
終わらせるようになったんだ。当然システムの出力に応じたパソコン外での
作業は生じてくる訳だけど、それは誰でもできることだから、テメーら自分でやってね。
凄く便利になってよかったね。ざまあみやがれ。
これで時間に余裕ができたので、本来の担当案件に集中して取り組むことができるし、
自分の退勤時間はほぼ定時になったし、有給もどんどん使ってやろうかと思うよ。
子育て期間に封印してた大好きなゲームを気の済むまで遊びたいんだ。
とりあえずSplatoon2とゼルダはやるし、ゲーミングPCをGTX1080で組んだから
STEAMで色々と買い漁るよ。
使ったことあるモノもないモノもごちゃまぜにして経験と雰囲気で書いてる。
▼PHP
Laravelは結構好き。DSL過ぎず、それなりにフルスタックで生産性もいい。
何よりLaravel本体のソースコードが読みやすいのがいい。
まともな日本語の情報が少ないのは弱点だけど、気になったところは本体のコードを読めばすぐに分かる。
最大の欠点はPHPってことだ。他のLL言語に比べてPHP自体の生産性は低い。セキュリティ面の不安も大きい。それに安心して後を任せられるようなPHPerは一握りしかいない。
▼Perl
Mojoliciousは結構好き。これもDSL過ぎず分かりやすい。CPANに豊富なライブラリ群もある。
Perlは可読性が悪いなんて言うけど、ちゃんとしたライブラリは普通に読みやすいよ。
最大の欠点はPerlってことだ。長期的に開発者を集めることを考えたら茨の道だろ？
今でこそ機械学習で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
Playが王道だけど最新バージョンになるほど情報が少ない。このあたりがRailsと違う。公式(英語)とか本体コードを読める人じゃないとつらい。
そもそもJava、というかJVM周りの知識がないと本番運用はつらいだろう。LL言語の運用経験しかない人は特につらい。LL言語でいうhot deployみたいなことがしたい時のやりかた分かってる？
コンパイルの遅さに耐えて開発し、運用時のGC問題を乗り越え、黒魔術を味方につけてライブラリのコードリーディングが出来るならいいんじゃないか。
Scalaを好むプログラマは関数型やらDDDやら意識高い人が多い。別にScala自体にそれらは必須ではないけど、そこら辺を意識しないならJava8でいいんじゃないかとも思う。
非同期処理で開発することの難しさに耐えられるの？
ベストプラクティスがなく、移り変わり激しいJS界隈に流されてオレオレで書いたコードを保守する自信があるならいいんじゃない。俺はない。
▼Go
API単体ならともかく、画面も担う普通のWebアプリを書くような言語じゃない。少なくとも今は。
正確に言うと書けないことはないけど、Webアプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットがほとんどない。
運用実績のノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない。
■結論
remoteでもlocalでも同じように動くという一点だけだと思うのよね。PGの単価が安いとかも有るけど。言語的には7.1からprivate const使えたり、まあ頑張ってる。
(※にも関わらず大本営が色々と改良しても、未だに新規案件で5.6とか持ち出す腐れ会社は滅びるべき)
なので、とにかくremoteでしか動かないコードってのやめてもらいたいんだよなあ。
Debuggerさえ使えるなら、magentoみたいなとんでもない糞コードの山(*1)であっても、コアコードを弄りまくったec-cube(特に2.x)であろうとも、縄文時代か？これ？みたいなオレオレフレームワーク(201x年でもオレオレ使ってるバカ会社が有るんですよ！)であっても追いかけて修正するなり殺すなり出来る。
ところがコード読み書きしないできないインフラ屋なんかが出張ってきて、やれvarnishだーSphinxだー云々やられるとDebugger使えないから死ねる。や、それを採用した人間が人類滅亡の時まで保守改修するならどうでもいいことなんだが。localにそれらを構築する？や、出来なくねえけどめんどくせえし。
wordpress最盛期。あの案件もこの案件もWordPressを使って、プラグインましましjqueryましまし脂マシマシな納品が星の数ほど生まれていく。「プラグインが最新バージョンに対応しないので、本体のバージョンアップができません」といってセキュリティホールだらけのwordpressが放置される。アホかと、バカかと。
フロントエンドはhtml,css,javascriptでつくるものだよ。expressをみて「javascriptでバックエンド書くの？気持ち悪い」っていってただろ。それと同じだ。いつまでphpでフロントエンド書くつもりだよ。phpで動的生成し続けるから、いつまでもwp headでwordpressのサイトってバレてアタック受けるんだよ。とりあえずurlの末尾にwp-adminってつけて確認されるんだよ。
分離しろ、分離。wordpressの管理画面が悪いとはいわない。あいつはいいやつだ。けど、wordpressでフロント書く必要はない。wordpressもrest apiだしただろ。更新はwordpressでやって、その情報をapiで取得してきたらいいんだ、それでいい。
wordpressでテーマをつくるのがキャッチだった頃からもう6年はたった。6年前といえば、Windows 7使ってた頃だよ。ヒカリエまだできてない。そんな頃のやり方つかって「これがスタンダードです」とかいってクライアントをだまくらかして楽しいか。さっさと2017年に追いつけよ。
当方、フリーの 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.cssとstyle.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 さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。
中学生の頃からパソコン大先生でスクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。
ちなみに、試験は紙ベースで、手書きでプログラミングをさせられる。つらい。
スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。
結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。
プログラミング初学者である人は苦労して書き方を覚えていたように思う。
脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである。
今学期、PHPを書く授業とPythonを書く授業を履修してみた。
PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストのコードを動かす気力のない自分にとっては最高の授業だ。
Pythonは、MeCabなどで形態素解析や構文解析をする授業で、サンプルコードを自分で考えてカスタマイズして毎回レポートで提出する。
Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。
書いたらすぐに目に見える成果が出るところが大きい。
自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。
そう思っていた矢先に事件が起こった。
最近、研究室に入ったところ先生が手当たり次第Javaを教え始めたのである。
せめてJavaScriptでいいからスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。
それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向を理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。
ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。
絶対にツマラナイだろう。
自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。
こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。
お願いだから、プログラミングを教えるのならツマラナイ授業をしないで欲しい。
生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。
別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。
自分は、分かりやすくて直感的なRubyというプログラミング言語が学校の授業で採用されるべき言語に間違いないと思う。
別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。
CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。
スクリプト言語を教えた後に、コンパイル言語、オブジェクト指向の概念を教えていくのがいいのではないだろうか。
みんなの意見を知りたい。
https://anond.hatelabo.jp/20170617024529
これに近い経歴のお方を、派遣会社からの紹介でお断りしたことが多々...
だって、急募即戦力ってオーダーに、PHPできるJSできるJavaもやってました！って触れ込みだったのに、CMS触ってたのがメインの経歴で、質疑応答も曖昧に「本読めばできます」「頑張ります」と言われても。
まあこの場合は単なるミスマッチでしかないし、こういう作業が今後なくなるかはよくわかんない。
つっても全く同じ経歴の人が2人いたとしていざ面接ってなったら、年齢とか、真面目そうとか、話が合いそうとか、本人の資質と全く関係ないところで選ばれてしまうと思うんだよね。
だってCMSやってただけじゃプログラマの資質わかんないもん。
逆にWordpressメインでやってきましたが、脆弱性回避のためにこんな事をやってきました！プラグイン同士相性悪いのをこう対処しました！みたいなほうが期待できそう。
今後プログラマとして飯喰ってくつもりだったら、先のトラバでも言われてたとおり家で趣味のプログラムとかしたほうがいい。
正直、CMS展開はプログラマの仕事じゃないと自分は思ってる。
もっとも書いてある経歴から察すると、ディレクターの方向に舵切ってみるのもいいんじゃない？
CMSや、PHPある程度でも判るWebディレクターって重宝するよ。プログラマからすると鬱陶しいけど。
こんな感じ？
うちの会社、Web系なんだから当然っちゃ当然なんだけど、案件の8割くらいはCMS案件なのよね。
それもWordPressは脆弱性出しすぎとかで保守しにくいってことでもうちょいマイナーなCMSが中心。
プログラマーとして入社してから今まで、デザイナーが渡してきたHTMLファイルをCMSのテンプレートとして構築する、
っていう作業が社会人生活の半分以上を占めていて、業務としてはPHPの簡単なプログラミングすらあんまり経験ない気がする。
CMSのテンプレートもif文とかループとかあるからこれもプログラミングといえばプログラミングなんだけど、
Web系っていうともっとPythonとかNode.jsとかVueみたいなキャピキャピした技術に触れるもんだと思ってたよ。
給料は安いけど割りかし残業も少なくて何かとヌルい会社だから今のところやめるつもりは特にないんだけど、
ディレクターとの調整とかExcel方眼紙で仕様書(多分一般的なSEが作るのよりはかなり簡潔なもの、勿論UMLとかはない)書いたり見積もりしたり操作マニュアル書いたりっていう経験はあっても
下流工程を生きるプログラマーとして例えば5年後10年後、技術的なキャリアとして「HTMLファイルをよくわからんCMSのテンプレートとして当て込むだけのことを長年やってきたおじさん」
が誕生したとして、果たして生きていけるのか心配になってきた。
僕は生きていけるのでしょうか。転職した方がいいんでしょうか。教えてください。
