  |
はてなキーワード: アプリケーションとは
日本語版がサービスインして9ヶ月ぐらい経ち精力的なアップデートが多い戦艦少女R。
Ver3.1になり、模様替え機能は付随され益々拡張に余念がない。
ゲーム内の収入をゲームに還元するその姿は近年稀に見るまともな運営と評するのが非常に正しい。
脳味噌がイカれた日本のソシャゲ運営からしたら真っ当な姿である。 残念ながら。
バトル鉛筆の販売やゴミの様なアプリケーションの負荷問題を誤魔化しながら、堂々とアプリケーション関係の公演したり恥を晒す白痴のような運営とまるで違う。
そのゲームの成り立ちが中国からだというから驚きを隠せなかった。
でも、そんな聖人君子ともいえる運営のゲームでも残念ながら不満点がないわけではない。
そんな不満点を上げていこうと思う。
戦闘の報酬になる新しいキャラクターの入手難易度が高い。 手に入れようと思えば同じマップを何十週も回らなくてはならない。
同じような状態は通常マップでも見られるが、それはいつか必ず手に入るだろうと言える。
しかし、イベント限定の場合は結構異なる。 イベント内の先行実装という形で実装されるのだが、これのドロップ率がよろしくない。
例を挙げるなら瑞鶴やオバノン（通称：じゃがいも）である。（ただし、瑞鶴は現在建造で入手可能）
先行実装という体であったとしても期間限定なのであればドロップ率をもう少し上げたほうがいいと私は思っている。
まあ、そのうち実装されるだけマシかもしれない。（ただし、ゲーベンは絶望的）
日本版ではまだなのだが、大陸版ではハードモードというのがあるらしい。
大陸版というのは中国でサービスインされているバージョンのことであるが、その大陸版ではハードモードが実装されているらしい。
要望なのでアレだが日本版ではある程度新規にやさしくするべきだと思う。 (2-4目安に)
新規と古参で差が出るのはしょうがないことなのだが、新規でも手に入れられるように配慮するべきである。
もし引退しても復帰したときにがんばれば遅れを取り戻せる環境を用意するべきだ。 新規や復帰勢をあらためて取り込みたいのであればそうするしかない。
もしこれで文句を言っている連中は優越感に浸りたいクズだし、害にしかならない。
これは装備やキャラクターを手に入れるチャンスがイベントしかないどこぞのゲームへのアンチテーゼである。
どんなソーシャルゲームにも不満点は必ずあるが、それを弾圧しない環境が必要だろう。
使ったことあるモノもないモノもごちゃまぜにして経験と雰囲気で書いてる。
▼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アプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットがほとんどない。
運用実績のノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない。
■結論
全国の介護士のみなさん、今日も資料作りに残業していませんか？
もう、やめましょう。
仕事で「Word」や「Excel」を使うのは、もうやめにしましょう。
パソコンで行うから効率がいいという勘違いにはもううんざりです。
いやいや、正確に言うと、正しい使い方も知らないのにパソコンを魔法の道具だと思ってしまっているのがダメなんです。
パソコンを使うからこそ効率よく管理ができる？そもそも、管理する必要があるようなことをやっているんですか？
いっそ、全部手書きにして、アナログで管理した方が早いんじゃないですか？
手書きじゃ綺麗に作れない、時間もかかるし手も疲れるというんなら、それこそタイプライターでも使ってみてはどうですか？
タイプライターなら、「Word」もないし「Excel」もない。
確かにパソコンを使えば様々な機能があり、それらの機能はとても便利そうに見えるし、使いこなすことによって効率よく仕事ができるような気がするでしょう。
でもそれが勘違いなんですよ。
より便利に、より効率的に、なんて考えてる暇があるならさっさと文字を入力したらいいんですよ。
より完璧なファイル管理の方法を模索している暇があるんなら、タイプライターででも文字入力して、印刷された紙を所定のファイルにでも綴じておいてください。
それなら、その紙に直接修正書きしてください。
修正箇所が多すぎる？
それならその紙は別のファイルにでも綴じて、新しい紙を作ってください。
それでもまだ多少の修正があるなら、それはやっぱり手書きで書きこんでおけばいいんです。
そうしておけば、より便利な「Excel」の機能を調べたり設定したりする必要もなくなります。
そうしておけば、より便利になった「Excel」のワークシートを見て、どのセルがどのシートのどのセルを参照していて今どうしてエラーが出ているのかを考える手間もなくなりますよ。
文字を書くにしても、「Excel」で作られた下品な枠組みが必要ですか？
そんなもん自作してる暇があるならね、市販の用紙を買ってくださいね。
とにかくね、介護士のみなさん、いや、そのボスのみなさん、パソコンは魔法の道具じゃないんです。
遊びで使うんならともかくね、仕事でパソコン使うには、あなた方ではノウハウが足りなさすぎるんですよ。
どうしてもパソコン使いたいっていうならね、もう「Word」も「Excel」も手放してください。
それでね、信頼できるソフトウェア会社なんかを探してね、こういう資料をこういう人たちが作るためのアプリケーションをこれくらいの値段で作ってもらって定期的に使用感についてのフィードバックも得てバージョンアップしていってほしいんですけど的なことを頼んで、しっかりと制作環境を整えていかないといけないわけ。
そこまでしたくない？
めんどくさいからさ。
その２を書きました→https://anond.hatelabo.jp/20170721113552
最近よく新聞やテレビでも取り沙汰されるようになったIoTという言葉。2020年には何億ものモノやセンサーが
ネットワークに繋がり、生活をより便利にしてくれるであろう技術と謳われています。
IoTを事業にしようと各社が立ち上がっており、大手携帯電話キャリアから車メーカーまで、様々な製品がひっきりなしに誕生しています。
これぞIoT黎明期と思わせるような新興っぷり。IoTの先駆けと言えば、やはり象印のみまもりポットでしょうか。
よくCMで耳にした「ポットを押したら電波がぴぴぴ♪」というやつですね。
前置きでした。
さて、このIoTの通信技術として注目されているのが、LPWA(Low Power Wide Area)とよばれる通信技術です。
IoT向けに特化した通信技術で、データ通信量は稼げないかわりに、少ない消費電力で遠くまで電波カバーエリアを伸ばしたものになります。
具体的な規格名を出すと、LoRaWAN / NB-IoT / Sigfox / Wi-SUNで、LoRaWANとSigfoxの電波到達範囲は、市街地で約3km、郊外で約8km。
物によっては見通し距離で約100km通信可能な製品も存在します。
ここ最近日本にもLPWAの波が押し寄せ、LoRaWANをはじめとする沢山のLPWAモジュールがサービス化に向けて提供され始めてきています。
LPWAは主にスター型（ゲートウェイと呼ばれる基地局に、多数の子機がぶら下がる方式）トポロジで利用される為、サービス提供においても
、事業者が基地局を持ち、ユーザに対して子機を購入してもらい、事業者の基地局を通して通信させる、いわば携帯電話のような
日本国内において、電波を利用して通信事業を行うためには２つの法を遵守しなければなりません。１つは電波法と、もう１つは電気通信事業法です。
どちらも総務省管轄の法規制で、日本の通信事業者はどちらかに必ず縛られます。
日本国内における電波の利用方法は、電波法によりかなり厳しく規制されています。LPWAの中でも特にLoRaWANとSigfoxに焦点を当てて言えば、
920MHz帯の電波を利用して通信しなければならないというルールがあります。
920MHz帯の電波は、無線LANと同じく誰でも免許フリーで利用できるアンライセンスバンド(ISMバンド)に定められており、運用ルールは
「920MHz帯テレメータ用、テレコントロール及びデータ伝送用無線設備」とされています。
920MHz帯で許可されている無線局は、空中線電力（電波出力）が20mW以下の特定小電力無線局と250mW以下の簡易無線局です。簡易無線局は登録制となっており、
デジタル簡易無線と同じような運用体制を取ります。ここで注意すべき点があり、簡易無線局は自営のみの利用に限定されているため、
他人へ貸し出すことが禁止されています。電波を長距離飛ばせる簡易無線局ですが、現在の電波法では不特定多数の利用者を想定している
LoRaWANやSigfoxで、電気通信事業用途として基地局に利用することができません。
これは日本Sigfoxパートナーである京セラコミュニケーションシステム（KCCS）も、総務省に対して簡易無線局を電気通信事業用途として利用
できるよう法整理を呼びかけています（参考：http://www.soumu.go.jp/main_content/000450876.pdf）
まとめますと
出力：20mW以下
・簡易無線局
出力：250mW以下
ビジネスモデル：自営のみ←
となるので、現状の電波法において、事業者が不特定多数に提供できる基地局の電波出力は必ず20mW以下の製品しか利用できません。
この法は、通信事業者としての規模の大小により、適切に監理ができる有資格者を配置する内容や、総務省に対する電気通信事故の
報告などについて細かく整理された法律です。（かなり噛み砕きました）
ここで論じたい点は上にも書いたとおり、規模の大小・サービスの提供形態によっては届け出電気通信事業者（以下、届け出）
もしくは登録電気通信事業者（以下、登録）に分類され、登録になると適切に有資格者の配置が必要になり、電気通信事業者としての責任が重くなるという点です。
・基地局を、第三者（例えばお客様）に利用させている。自分のために使うのではない。（電気通信役務に該当する）
・基地局を、サービスとして提供している。（電気通信事業に該当する）
・基地局は、事業者が任意の場所（公園から企業のオフィスから電柱まで）に設置する。（事業法の適用除外に該当しない）
・そのサービスで、利益※1を上げている。（電気通信事業を営むことに該当する）
・電気通信回線を設置し、端末系伝送路設備※2の設置の区域が一の市町村の区域を超える。（電波の到達範囲が広い為、一の市町村を超えます）
※1利益：ここでいう利益とは、金銭的な収益はもちろんですが、金銭を得ないが自分(自社)に有利に働く内容であれば、利益を得ていると見なされます。
例えば、基地局の位置を第三者に宣伝して貰う事もそうですし、２者間でゲートウェイの相互利用（使わせ合う）も利益にあたります。
より詳しい電気通信事業参入マニュアルは、総務省が提供しています（参照：http://www.soumu.go.jp/main_content/000477428.pdf）
この5つの条件を揃えたサービスを提供する事業者は、登録電気通信事業者になる必要があります。
登録に課される条件の中でなかなか厳しいのは、有資格者（電気通信主任技術者）の配置です。
サービスを展開する全ての都道府県に事業所を置き、そこに資格者を配置しなければなりません。
NTTやKDDI、各地方のケーブルテレビ局は自前の伝送路（光ファイバや電話線等）を持っている為、登録として事業を行っています。
登録電気通信事業者のリストは、総務省が公開しています。（参考：http://www.soumu.go.jp/johotsusintokei/field/data/gt010402.xls）
このLPWA事業における電気通信事業法の落とし穴は、誰でも（個人でも）すぐに始められる手軽さがありながら、通信事業が本業である事業者と同じ括りで厳しい縛りがある点です。
LPWAに参入してきている事業者は、もともとアプリケーションサービスやIoT向け格安SIMカードを提供していた事業者ばかりです。
ただし、Sigfoxに於いてはKCCSが既に登録となり、全国での提供を辞さない本気の構えです。
電波法的には、アンライセンスバンドということで "免許不要！" と強調したくなるのは十分理解できますが、それはあくまでも電波法に係る話であって
電気通信事業法までもが免除されるという話では決してありません。法は法として守るために存在し、罰則規定もちゃんとあります。（罰金または懲役）
個人的な感想では少し厳しすぎないかと思うところはありますが、KCCSもそれを呑んで事業をするということで、守っている真面目な事業者も居るわけです。
最後になりますが、LoRaWANをやっている某事業者はいかがですか。
追記：登録電気通信事業者のリストを追記しました(2017/07/07 14:40)
追記：免許不要に関する過大解釈について追記しました(2017/07/07 14:57)
追記：電気通信事業参入マニュアルを追記しました(2017/07/07 16:02)
追記：電気通信事業法による利益の解釈について追記しました(2017/07/07 18:37)
追記：その２を書きました→https://anond.hatelabo.jp/20170721113552（2017/07/21 11:40）
コメント：http://b.hatena.ne.jp/entry/341443907/comment/toruuetani
返信：
電気通信事業法において、提供する親機（基地局）は簡易無線局か特定小電力無線局かは、実は関係ありません。
電気通信事業法ではどちらであっても、提供するものは端末系伝送路設備とされますので、５つの条件を満たすと登録として事業する必要があります。(2017/07/07 15:19)
コメント：http://b.hatena.ne.jp/entry/341443907/comment/kentamagawa
返信：
社長氏自らコメントありがとうございます。リンク先を確認し、確かに373号が未採番である点を確認しました。また、登録として事業をされるのは大変素晴らしいことだと思います。
ですが、SORACOM Air for LoRaWANのサービス開始は2017/02/07からと存じておりますが、2017/06/01時点のリストでなぜ登録電気通信事業者として名前が上がっていないのでしょうか。
少なくともサービス開始から06/01までは登録をせずに電気通信事業を営んでいるということになります。登録なしに登録と同じ電気通信役務を提供するのは、電気通信事業法第9条違反です。
通常、サービスを策定する際に法的な課題をきちんとクリアするため、サービス提供前には登録するか、間に合わない場合登録されるまでサービス提供を伸ばすのが一般的ではないでしょうか。
社長ご自身のツイート（https://twitter.com/KenTamagawa/status/883473160347172866）にもある通り、「都市伝説」と揶揄されるのも理解できかねますし、
登録してから事業をするに当たっては問題ありませんが、過去には事実であったことに変わりはありません。そこはどうご説明されるのでしょうか(2017/07/08 12:06)
コメント：
ご指摘ありがとうございます。
補足させていただきますと、まず、所有モデルに関してサービス提供を行うことについて電気通信事業の登録は不要と認識しております。そのため、2月より販売、3月よりゲートウェイの出荷をさせていただいており「サービス開始」と表現させていただいております。
また、共有サービスモデルについては所有モデルでのゲートウェイより遅れて提供を開始するとともに当初は電気通信事業を営む形にならないようご提供しており、電気通信事業の登録を行った上でサービス提供を開始させていただいております。
弊社からこの形態が適法か違法かはご回答する立場にありませんが、サービス内容、特に共有サービスモデルに関し、単にお客様所有のゲートウェイを共有するのではなく、ゲートウェイを弊社が所有した上でユーザ様に提供（貸与）することで、電気通信事業の届出・登録に関し、お客様の登録は不要で弊社が登録を行う様態とすること等、2月のサービス発表前に総務省の各関連部門のご担当者様とは事前にディスカッション・アドバイスをいただくとともに、登録の手続き等、上記でご説明させて頂いた内容も含め継続的にお話をさせていただいております。
弊社も電気通信事業法・電波法をはじめとした各関連法規・法令を遵守することは大変重要と考えております。今後とも、お気付きの点はご指摘頂ければ幸いです。
返信：
（社長氏のFacebookでコメントがあったと教えていただきましたので、追記です）補足ありがとうございます。また、休日にも関わらずくだらないブログに付き合って頂き恐縮です。
個人的に幾つか質問がございますので、任意でご回答頂ければと存じます。
①"所有モデルに関してサービス提供を行うことについて電気通信事業の登録は不要と認識しております" とありますが、こちらは確かに御社自身は電気通信事業法としての縛りを受けないサービス提供方法であることは理解しております。
ですが、所有モデルも共有設定が可能であり、機能としてそれを謳っているところについては、お客様自身が共有設定で他者に利用させている場合、GWを購入されたお客様が電気通信事業法において電気通信事業を営んでいると判定されるのではないでしょうか。
これだけでも最低限届け出は必要であり、場合によっては登録まで必要であると認識しております。
補足頂いている通り、共有モデルにおいては御社が登録事業者となり、お客様には電気通信事業者としての縛りを受けずにサービスを利用して頂ける事に関しては、私も同認識です。
②"当初は電気通信事業を営む形にならないよう提供" とありますが、それは事業法の適用除外となる形態で提供されていて、登録されてからサービスの提供形態を変更されたということでしょうか。
コメント：http://b.hatena.ne.jp/entry/341443907/comment/ganymean
返信：
実は私も同じような事を考えていました。ですが、これには該当しないようです。
と言いますのも、 "基幹放送に加えて基幹放送以外の無線通信の送信をする無線局の無線設備である場合" とは、基幹放送(テレビ等）用の設備を遠隔操作するために併設して利用する無線設備と解釈されるためです。
LoRaWANをはじめとするLPWA無線局の主な利用用途は基幹放送等には全く関係ない無線局ですので、事業を行う場合は登録事業者になる必要があります。もちろん、LPWAの無線局を上記のような利用方法で利用する場合は、登録の必要はありません。(2017/07/14 18:17)
当方、フリーの 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日以降も会社に関する説明も仕事の説明もなし。唐突に「これやってください」って書類置かれて、どうしたらいいか聞いたら心底面倒臭そう。
なんだこの会社はと思いながらもまあいろんな会社があるだろうと1ヶ月我慢してみたんだが、昨日役員に呼ばれて「消極的で仕事やる気がないのか？」と
「は？」
と思った。こっちはいつ仕事振られてもいいように会社の座席表覚えたり、マニュアルも台帳も未整備だからPCの台数やネットワーク把握したり、業務改善に繋がりそうなアプリケーションの研究とかしてたんだが、どうやらそういうことではなくて、
・外線の電話に誰よりも早く出て、
・何か仕事ありませんか？
と聞いて回るのが新人のあるべき姿らしい。
なるほど
素晴らしいじゃないか。社内SEの給与レンジで雇った人間を電話番にできるほど余裕があるんだなこの会社。ということで、今朝はこれから仕事辞めるって言ってくる。
仕事を与えるのは給料払う側の義務だろうと思うんだ。社員はそれに答えるのが仕事。自分から仕事を探せる人間？それは私だが、その仕事は御社の中とは限らないんだぜ
一応言っておくけど、電話番をバカにしてるわけじゃない。会社の窓口として大事な仕事だと思っているからこそ、新人がやるような仕事じゃないと思っている。そこがわからない会社は東証一部でも二流だなと
cruby を使っているならunicornにしてください。
crubyには、GVLがあるのでスレッドで動くアプリケーションサーバは、worker数を増やしたところで一定より性能は向上しないと思うんだよね。だってWEBアプリケーションってCPUバインドだもん。
アプリケーションがDB以外へのIOでリソースを食っているなら設計を見直したほうがいいし、最悪pumaを使ってください。
ちなみに開発環境でpumaが標準になっているのは、webrickと比べて静的ファイルの配信がはやく終わるからなんだよ。間違っても本番環境でpumaを推奨している訳じゃないからね。
ちなみにherokuの場合は、フロントにwebサーバを配置できないので、スロークライアントにunicorn workerを取られるくらいならpumaにします、という覚悟が必要。
仕事内容を簡単に言うと、そこでずっと使われているアプリケーションの保守（改善・機能追加）で、そのアプリの開発統合環境を私は知らないけれども、そこも教えていくので一緒にやりましょうというもの。
業務自体は１日８時間で、残業もなくやらせてもらってる。（実際ものを覚えても残業は少ないみたい）
出向先になる職場の人も優しくて分からない点は教えてくれるし、興味があればでスポーツやFPSの誘いもあって、それに乗らなければならないというわけでもない。
何が問題かといえば、手取りが１５しかないこと。（ボナは0.5ヶ月）
出向先の方が２～３００万クラスの車乗ってて「車持たないと不便じゃない？」と言われたり、スポーツも金のかかるスポーツを誘われたりして生活レベルに差を感じる。
正直私もスポーツ（ゴルフとか）したいし車も持ちたいとは思うけれども、それをしたらもう貯金はできないよね。
大企業から受注を受けている会社に派遣で入る社員。つまりは出向SEだが、ここで頑張っても給料増える気がしない。４０代になっても手取り２０超えないのではないかと思ってしまう。（いくらなら妥当なのだろう？）
奴隷の鎖自慢は駄目だろう。もうそれをした時点で辞めたほうが無難ではないか？
去年の夏ぐらいから新たなプロジェクトがあり、そこに参加しているのだけどいまいちモチベーションが上がらない。
タスク管理の方法としては、毎度おなじみのExcelをつかって、日々の進捗を共有のファイルに書き込んでいくというものだ。
別にExcelを使っている企業なんて山ほどあるだろうし、とりわけそこに突っ込む気はないのだけど、
Excelで管理されたタスクを見て、「今日も一日頑張るぞい！」という気持ちになるのは難しいものだ。
今のプロジェクトではWebアプリケーションの開発をしているのだけど、その画面ごとに1機能として管理している。
1画面1機能なので、どれだけ複雑な機能でも、それが1画面に収まっていれば1機能なのだ。
さらに日々の進捗としても、その1機能に対し何％進んでいるか、といったアバウトな感覚で管理されており、
まあ、こんなものかというどんぶり勘定を日々報告することになる。
PMも本当に仕様を理解しているのか怪しいところがあって、日々の報告で多少進捗を盛っても気づかない。
周りの開発者は薄々感づいているかもしれないが、特に指摘が入るわけでもない。
こんな状況なので、プロジェクト開始時点ではMAXだったモチベも日に日に下がり、
今では、とりあえず動くものができればいいだろ的なまでになっている。
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
ベンチャーキャピタルしてます。昔からずーっと疑問だったが、Webサービスに技術的な優位性なんてある？
たまに「うちのサービスはアルゴリズムが凄いんです！！！」とアピールしてくる会社がある。私はエンジニアではないし、コーディングもしたことないから、その凄いアルゴリズムを正確に評価ができない。
でも、サービスにとって重要なのは、そのサービスがどうやって動いているかというよりは、お客さんがその体験を通じてどう思ったかのほうじゃないのかな。Webサービス（アプリ含めて）なんて、クライアントアプリケーションとサーバーの組み合わせでしかないから、簡単に模倣できるんじゃないの（適当）？事実、そういう戦略を取っている会社はいっぱいあるし、そもそも日本のベンチャーはアメリカのスタートアップの模倣が多い。
だから、サービスに競争優位性があるとしたら、技術そのものによるものではなく、新しい技術を取り込んで顧客体験に還元できる組織風土や組織体制だったり、既存システムの改善改良を続けるスピード感だったり、そういう単純比較が難しいところじゃないかなと思っている。となると、前述のアルゴリズム凄いアピールは、よくわかっていない投資家を騙くらかそうとしているか、単純に本気でアルゴリズムの優位性を信じているか、どちらかということになる。私はひねくれているので、前者だろうと思って「うちのアルゴリズムは凄いんです」はほとんど評価してこなかった（評価できなかったんだけど）。
４行にまとめました
・コミュニケーションが少ない
・他にも色々ヤバイ
他のIT会社がこんな感じと違っていたら申し訳ないです。それと読みづらかったらすみません。
当方１９歳。お金をもらいながらスキルの得られる「有給インターン」に申し込みました。
今から書くのはそこでの話です。
IT系のバイトは基本実務経験がないと受けられないので、僕は「未経験歓迎」というところを探していました。
大阪は都会といえど、東京の1/4程度しかIT系の求人はありません。
そこは未経験歓迎で、土日もやっているところでした。
早速応募して、いざ面接。履歴書書いているときや、会社に行くまではすごく緊張しました。
そして面接が始まったのですが、なぜここを受けたのか、やりたい業種は何か。という話になり、話の感じからもう入って何かをするテイで進んでいるのだと思いました。
ありがたいことに、トントン拍子で採用され、数日後から勤務することになりました。
（サイトで書かれていた、”研修期間あり”がここで完全無給だと知らされたのは引っかかりましたが…）
それからしばらく経ち、会社に行って挨拶をし、何かすることはないか（パソコンのパスワードすら知らない状態なので）聞きました。
挨拶への反応も、業務に関しての回答もないので戸惑いましたが、社員さんにパスを打ってもらい、ログインしました。
ここまで数分の出来事ですが、アルバイトで見てきた他の業種とは雰囲気が違うな と思いました。他の会社よりコミュニケーションが控えめな印象でした。
それから何をすれば良いのか社員さんに訪ねたのですが、それはSkypeで話すとのことでした。
本来送るべき内容のメールの送信を忘れていたのか、そこでSkypeの登録と、登録に使う会社用のメールアドレスを送っていただけました。
先程ログインしてもらったパソコンを使い、Skypeの登録をしようとしたのですが、ここでかなり記憶に残る出来事がありました。
クラックされているのか、定かじゃないのですが、少なくともライセンス認証されていなくて、あのデスクトップの背景が真っ黒のやつでした。
気になって、コントロールパネルからOSは何なのか見たのですが、Windows7のUltimateでした。
僕はPCを組んだことはありますが、OSのこだわりはないので、一番安いHOMEにしていました。会社のパソコン事情はわからないのですが、一般的なIT会社はUltimateを始め、HOME以上のエディションを使うのでしょうか？
面接の時に、「在宅でできるから、やれるなら在宅が良いよ」と言われたのを思い出しました。社員さんの理由は、「パソコンが古い」だったので、７を見たとき新しいじゃんと思いました。
僕は実際に相談して、作業の流れが把握できたほうがよいので本社で初めは仕事をしようとしたのですが……
アカウントを作成しようと思い、デスクトップにあるブラウザーを使いました。
Chromeは開発用に使われているのか、ショートカットの名前がイジられているので使いませんでした。そして、IEもアイコンからしてめっちゃ古いので、不具合を避けるためにやめました。
他にあったのが、FireFox。それを使いました。
もう使いものにならないです。動いてるアプリケーションはFireFoxぐらい。通知センターなどを見てもIMEすら切られているのか、漢字も打てない。
開いた瞬間、アジア系無修正ビデオの画面が別ウインドウで出るのは、控えめに言って泣きそうでした。
自分もこういう汚染は経験があったので、ショートカットのプロパティを開き、追加で書かれているURLなどを削除しました。開発で使っていたら申し訳ないのですが、凄い重かったのでごめんなさい。
Skypeを登録し、それでチャットを始めるのですが、IMEが効いてないのでひらがなをで検索してメモ帳を駆使して、半ば怪文書を作る形で連絡を取ることになりました。
社員さんに「個チャはやめて」と、グループの方へ回されました。
そこで挨拶をして自分の素性を話し、送られてきたDropboxのファイルを見ながら作業をしました。
というのも、会社のサイトに登録するのです。そこに登録するメアドを書いてたらニコニコ動画の広告や、DMMの広告に飛ばされることが多々あり、悲しくなりました。
自分のプロフィールを書くと本登録ができるのですが、そのときにされるとマジで死にたくなります。
そもそもメアドを送って仮登録した返信メールが、迷惑メールに送り込まれているところが面白かったです。探すのに１０分かかりました。
課題をもらって、それを達成していくのですが、課題を保存するためのクラウドはどうするのだろう？というのが今でもずっと心に残っています。
配布されたメアドで登録するのは良いものの、メールボックスが開けないので認証ができません。
こんなに重いので、Dropboxのテキストを読むのですら大変で作業なんてできる状況じゃありませんでした。
次の日から在宅をしようと、配布されたメアドで自宅のパソコンでSkypeログインしようとしたのですが、エラーで入れません。
調べたら、迷惑メールの送りすぎか何かでメールアカウントが凍結されたそうです。
そのまま今に至るのですが、どうすりゃ良いんだろう。。
IT業界がこんな感じ、というなら夢半ばで他の道を探すしか無いし、働けないにしても「作りたいものがないから、プログラミングの勉強できない」という自分のために課題を出してもらった以上、それは達成してみたかったです。
友達にもこの会社を勧めたのが申し訳ないし、連絡が有耶無耶で社員さんにも申し訳ない。
今年度卒業予定であり就活手前ですが、今まで何もしてこなかった自分への苛立ちと後悔を感じています。なぜそんなことになったのかを自分の気晴らしに書きます。
専門学校に入学するのは「プログラマになるための最短ルート」だと思い、学費も大学より安いことから専門学校に入学。前年度は学校では基本情報技術者の勉強をするだけ。基本情報技術者を無事取得しましたがプログラミングの授業はゼロに等しかったので、個人で企業のapiとajaxを利用した簡易的なwebアプリケーションを作ったりしました。
今年度に入り学科の就活解禁日より二足ほど早く、プログラミングスキルを判定できる新卒エンジニア向け就活サイトで大企業様のスカウトを受け採用試験に挑戦。結果は不採用で通知メールにはコミュニケーションは問題なかったが、技術力が足りないと書かれていました。
私はCentOSで多目的サーバを高校時代から運用し、webアプリケーションを作った経験と国家資格をもあれば十分だろうと思っていたことが甘かったと痛感。
面接（というより面談）の対応をしてくださった方はとても良い方で、面談の中でエンジニアは常に最新技術へのアンテナを貼るべきで学生のうちは何でも作ってみるべきだと教えてくれました。
その教え通り私は今何かを作ろうとしています。それでも自分の中でプライベートの時間をプログラミングに割くことができず娯楽に使ってしまう心の弱さに苛立ちを感じているのです。
何とかしてプログラムを完成させ、社内開発の会社に入りたい…そう思いながら今日も生きます。
