「アプリケーション」を含む日記 RSS

はてなキーワード: アプリケーションとは

2017-07-15

戦艦少女をやっていて思う運営への要望

日本語版サービスインして9ヶ月ぐらい経ち精力的なアップデートが多い戦艦少女R。

Ver3.1になり、模様替え機能は付随され益々拡張に余念がない。 

ゲーム内の収入ゲーム還元するその姿は近年稀に見るまともな運営と評するのが非常に正しい。

脳味噌イカれた日本ソシャゲ運営からしたら真っ当な姿である。 残念ながら。

バトル鉛筆販売ゴミの様なアプリケーションの負荷問題を誤魔化しながら、堂々とアプリケーション関係の公演したり恥を晒す白痴のような運営とまるで違う。

そのゲームの成り立ちが中国からだというから驚きを隠せなかった。

でも、そんな聖人君子ともいえる運営ゲームでも残念ながら不満点がないわけではない。

そんな不満点を上げていこうと思う。

イベント限定の新しいキャラクターを入手する難易度を下げたほうが良い。

戦闘報酬になる新しいキャラクターの入手難易度が高い。 手に入れようと思えば同じマップを何十週も回らなくてはならない。

同じような状態は通常マップでも見られるが、それはいつか必ず手に入るだろうと言える。

しかし、イベント限定場合結構異なる。 イベント内の先行実装という形で実装されるのだが、これのドロップ率がよろしくない。

例を挙げるなら瑞鶴やオバノン(通称じゃがいもである。(ただし、瑞鶴現在建造で入手可能

先行実装という体であったとしても期間限定なのであればドロップ率をもう少し上げたほうがいいと私は思っている。

まあ、そのうち実装されるだけマシかもしれない。(ただし、ゲーベンは絶望的)

ハードモード実装するならばイベントの通常マップ難易度を下げたほうがいい。

日本版ではまだなのだが、大陸版ではハードモードというのがあるらしい。

大陸版というのは中国サービスインされているバージョンのことであるが、その大陸版ではハードモード実装されているらしい。

要望なのでアレだが日本版ではある程度新規にやさしくするべきだと思う。 (2-4目安に)

ハードモード実装されたアイコンなどは別イベント報酬品で引き換えられるようにする

新規古参で差が出るのはしょうがないことなのだが、新規でも手に入れられるように配慮するべきである

もし引退しても復帰したときにがんばれば遅れを取り戻せる環境を用意するべきだ。 新規や復帰勢をあらためて取り込みたいのであればそうするしかない。

もしこれで文句を言っている連中は優越感に浸りたいクズだし、害にしかならない。

これは装備やキャラクターを手に入れるチャンスがイベントしかないどこぞのゲームへのアンチテーゼである

締め

どんなソーシャルゲームにも不満点は必ずあるが、それを弾圧しない環境必要だろう。

もし不満点を弾圧してしまえば、そのゲーム未来絶望的だろう。

2017-07-11

退職理由

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とか

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

結論

完璧選択などない。

2017-07-09

仕事パソコンを使うのはもうやめにしよう

全国の介護士のみなさん、今日資料作りに残業していませんか?

もう、やめましょう。

仕事で「Word」や「Excel」を使うのは、もうやめにしましょう。

パソコンで行うから効率がいいという勘違いにはもううんざりです。

パソコンでやるから効率が悪いんです。

いやいや、正確に言うと、正しい使い方も知らないのにパソコン魔法の道具だと思ってしまっているのがダメなんです。

その資料、本当にパソコンじゃないとだめなんですか?

Word」や「Excel」を使わないとだめなんですか?

パソコンを使うからこそ効率よく管理ができる?そもそも管理する必要があるようなことをやっているんですか?

いっそ、全部手書きにして、アナログ管理した方が早いんじゃないですか?

手書きじゃ綺麗に作れない、時間もかかるし手も疲れるというんなら、それこそタイプライターでも使ってみてはどうですか?

タイプライターなら、「Word」もないし「Excel」もない。

まり余計な機能がない。

確かにパソコンを使えば様々な機能があり、それらの機能はとても便利そうに見えるし、使いこなすことによって効率よく仕事ができるような気がするでしょう。

でもそれが勘違いなんですよ。

より便利に、より効率的に、なんて考えてる暇があるならさっさと文字入力したらいいんですよ。

より完璧ファイル管理方法模索している暇があるんなら、タイプライターででも文字入力して、印刷された紙を所定のファイルにでも綴じておいてください。

修正必要

それなら、その紙に直接修正書きしてください。

修正箇所が多すぎる?

それならその紙は別のファイルにでも綴じて、新しい紙を作ってください。

それでもまだ多少の修正があるなら、それはやっぱり手書きで書きこんでおけばいいんです。

そうしておけば、より便利な「Excel」の機能を調べたり設定したりする必要もなくなります

そうしておけば、より便利になった「Excel」のワークシートを見て、どのセルがどのシートのどのセルを参照していて今どうしてエラーが出ているのかを考える手間もなくなりますよ。

文字を書くにしても、「Excel」で作られた下品な枠組みが必要ですか?

そんなもん自作してる暇があるならね、市販の用紙を買ってくださいね

とにかくね、介護士のみなさん、いや、そのボスのみなさん、パソコン魔法の道具じゃないんです。

遊びで使うんならともかくね、仕事パソコン使うには、あなた方ではノウハウが足りなさすぎるんですよ。

きっぱり諦めて、アナログ世界に戻りましょうよ。

どうしてもパソコン使いたいっていうならね、もう「Word」も「Excel」も手放してください。

それでね、信頼できるソフトウェア会社なんかを探してね、こういう資料をこういう人たちが作るためのアプリケーションをこれくらいの値段で作ってもらって定期的に使用感についてのフィードバックも得てバージョンアップしていってほしいんですけど的なことを頼んで、しっかりと制作環境を整えていかないといけないわけ。

そこまでしたくない?

それならさ、ほんと、もっとアナログにいこうよ。

めんどくさいからさ。

2017-07-07

IoT黎明期のLPWA事業と法

その2を書きました→https://anond.hatelabo.jp/20170721113552

2017/07/21 11:40

  

(法を守らない事業者が居るんじゃないかという話です)

最近よく新聞テレビでも取り沙汰されるようになった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は主にスター型(ゲートウェイと呼ばれる基地局に、多数の子機がぶら下がる方式)トポロジで利用される為、サービス提供においても

事業者基地局を持ち、ユーザに対して子機を購入してもらい、事業者基地局を通して通信させる、いわば携帯電話のような

サービスモデルが非常に多い状況です。

  

日本国内において、電波を利用して通信事業を行うためには2つの法を遵守しなければなりません。1つは電波法と、もう1つは電気通信事業法です。

どちらも総務省管轄法規制で、日本通信事業者はどちらかに必ず縛られます

ここからは少し専門的な話になります

  

  

  

1■電波法観点で見た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以下の製品しか利用できません。

  

  

  

2■電気通信事業法観点で見たLPWA事業

この法は、通信事業者としての規模の大小により、適切に監理ができる有資格者を配置する内容や、総務省に対する電気通信事故

報告などについて細かく整理された法律です。(かなり噛み砕きました)

ここで論じたい点は上にも書いたとおり、規模の大小・サービス提供形態によっては届け出電気通信事業者(以下、届け出)

もしくは登録電気通信事業者(以下、登録)に分類され、登録になると適切に有資格者の配置が必要になり、電気通信事業者としての責任が重くなるという点です。

簡単にまとめますと、

  

基地局を、第三者(例えばお客様)に利用させている。自分のために使うのではない。(電気通信役務に該当する)

基地局を、サービスとして提供している。(電気通信事業に該当する)

基地局は、事業者任意場所公園から企業オフィスから電柱まで)に設置する。(事業法適用除外に該当しない)

・そのサービスで、利益※1を上げている。(電気通信事業を営むことに該当する)

電気通信回線を設置し、端末系伝送路設備※2の設置の区域が一の市町村区域を超える。(電波の到達範囲が広い為、一の市町村を超えます

※1利益:ここでいう利益とは、金銭的な収益はもちろんですが、金銭を得ないが自分(自社)に有利に働く内容であれば、利益を得ていると見なされます

例えば、基地局位置第三者宣伝して貰う事もそうですし、2者間でゲートウェイ相互利用(使わせ合う)も利益にあたります

※2端末系伝送路設備電気通信事業法で見た、基地局区分

より詳しい電気通信事業参入マニュアルは、総務省提供しています(参照:http://www.soumu.go.jp/main_content/000477428.pdf

  

この5つの条件を揃えたサービス提供する事業者は、登録電気通信事業者になる必要があります

登録に課される条件の中でなかなか厳しいのは、有資格者電気通信主任技術者)の配置です。

サービスを展開する全ての都道府県事業所を置き、そこに資格者を配置しなければなりません。

  

NTTKDDI、各地方ケーブルテレビ局は自前の伝送路(光ファイバ電話線等)を持っている為、登録として事業を行っています

登録電気通信事業者リストは、総務省が公開しています。(参考: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)

追記:その2を書きました→https://anond.hatelabo.jp/20170721113552(2017/07/21 11:40)

  

コメントhttp://b.hatena.ne.jp/entry/341443907/comment/toruuetani

返信:

電気通信事業法において、提供する親機(基地局)は簡易無線局特定小電力無線局かは、実は関係ありません。

電気通信事業法ではどちらであっても、提供するものは端末系伝送路設備とされますので、5つの条件を満たすと登録として事業する必要があります。(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を購入されたお客様電気通信事業法において電気通信事業を営んでいると判定されるのではないでしょうか。

これだけでも最低限届け出は必要であり、場合によっては登録まで必要である認識しております

補足頂いている通り、共有モデルにおいては御社登録事業者となり、お客様には電気通信事業者としての縛りを受けずにサービスを利用して頂ける事に関しては、私も同認識です。

②"当初は電気通信事業を営む形にならないよう提供" とありますが、それは事業法適用除外となる形態提供されていて、登録されてからサービス提供形態を変更されたということでしょうか。

差し支えなければ、登録電気通信事業者としての登録日をご教示下さい。

私自身、事業法学習中の身ですので、誤りがあればご指摘下さい(2017/07/08 19:40)

  

コメントhttp://b.hatena.ne.jp/entry/341443907/comment/ganymean

返信:

実は私も同じような事を考えていました。ですが、これには該当しないようです。

と言いますのも、 "基幹放送に加えて基幹放送以外の無線通信送信をする無線局無線設備である場合" とは、基幹放送(テレビ等)用の設備遠隔操作するために併設して利用する無線設備解釈されるためです。

この "基幹放送に加えて" が大事なところです。

LoRaWANをはじめとするLPWA無線局の主な利用用途基幹放送等には全く関係ない無線局ですので、事業を行う場合登録事業者になる必要があります。もちろん、LPWAの無線局を上記のような利用方法で利用する場合は、登録必要はありません。(2017/07/14 18:17)

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-07-04

Windows10も悪くないと思うようになった

昨年のアップグレード騒動をキッカケにMicrosoftに見切りをつけMacユーザーになったが、最近Windows10も悪くないと思うようになった。

アプリケーションMacより優れているし使用している周辺機器との相性も良い。何より安価部品を組み合わせてPC自作できるのが魅力だ。

Macのようにセキュリティソフトを入れるとブラウザが重くなってイライラすることもない。欠点があるとすればシステムフォントが汚いことぐらいだろう。

次のPCをどちらにするか考えてしまう。

2017-07-03

ビッグデータ [1][2](英: big data)とは、市販されているデータベース管理ツールや従来のデータ処理アプリケーションで処理することが困難なほど巨大で複雑なデータ集合の集積物を表す用語である

なんだからそもそも「Excellでは処理できないような巨大データ」を指すんじゃねえの。

2017-06-30

anond:20170630212139

情報処理安全確保支援士すごいね

俺は情報処理安全確保支援士取る気はないけど、ずいぶん昔にPMアプリケーションエンジニア試験TRYしたことを思い出した。

2017-06-28

ちょっとから会社辞めてくる

とある東証一部企業に入って1ヶ月

初日に社訓みたいの唱和してるし、何も教えられないから嫌な予感はしたんだが、とりあえず黙ってた

2日以降も会社に関する説明仕事説明もなし。唐突に「これやってください」って書類置かれて、どうしたらいいか聞いたら心底面倒臭そう。

なんだこの会社はと思いながらもまあいろんな会社があるだろうと1ヶ月我慢してみたんだが、昨日役員に呼ばれて「消極的仕事やる気がないのか?」と

「は?」

と思った。こっちはい仕事振られてもいいように会社座席表覚えたり、マニュアルも台帳も未整備だからPCの台数やネットワーク把握したり、業務改善に繋がりそうなアプリケーション研究とかしてたんだが、どうやらそういうことではなくて、

・外線の電話に誰よりも早く出て、

・何か仕事ありませんか?

と聞いて回るのが新人のあるべき姿らしい。

なるほど

素晴らしいじゃないか社内SE給与レンジで雇った人間電話番にできるほど余裕があるんだなこの会社。ということで、今朝はこれから仕事辞めるって言ってくる。

仕事を与えるのは給料払う側の義務だろうと思うんだ。社員はそれに答えるのが仕事自分から仕事を探せる人間?それは私だが、その仕事御社の中とは限らないんだぜ

一応言っておくけど、電話番をバカにしてるわけじゃない。会社の窓口として大事仕事だと思っているからこそ、新人がやるような仕事じゃないと思っている。そこがわからない会社東証一部でも二流だなと

2017-06-24

なに?インフラエンジニアって大変なの?

でも日本ってアプリケーションエンジニアの方がよっぽどクソみたいな仕事多いじゃねえか

一体どんなエンジニアになればいいんだよ 教えてくれよ

2017-06-20

高野連はさ

メガネ視力矯正するのはセーフと考えているんだよね。

だったら、投手の投げた球の軌跡と到達予想時刻とを網膜に表示させるアプリケーション入れた学生を出場させても良いはずだ。

もちろん初めはダメだったんだろう。

けれど、遺伝子を改変する事で網膜表示を形質として発現させる人が増えて以降、生まれながら網膜ネットワークを持つ子供も増えたわけ。

まれながら投球や打球が「良く見える」球児たち。彼らをルール違反として退けるのは差別だと思う。

2017-06-18

Web未来

データベースはそれ専用のGoogle App Engine的な外部サービスがほぼタダで使えて、

ブログとかECサイトくらいなら外部サービス連携させるだけでStaticなサイトで充分になる。

そんでStaticなサイトGithub Pagesみたいに無料で使えるものを使えば

簡単ECサイトくらい無料作成から運用までできるようになる。

1年後くらいにはそうなってんじゃね。

オリジナルアプリケーションが作りたいとかじゃなければWebハードルもっと下がってくるはず。W

2017-06-16

https://anond.hatelabo.jp/20170616103019

今のゲームってアプリケーションデータHDDダウンロードが当たり前になってるから買った当日にはプレイできないなんてザラ。

アサシンクリード映画化した時にアサシンクリード4とアサシンクリードユニティが100円になってたけど、買ってから実際に遊べるのはまあ2-3日後だわな。

通なゲーマーはやりたいゲームを買う時はすぐに遊べるゲームもついでに買う。

ニーアオートマタグラビティデイズ2、Fallout4とPreyのように。

この待ち時間で熱がなくなりがちだから開発者にはなんとかしてほしい部分だけど...

PS4フォールアウトがセールで安かったから買った

すぐDL終わったと思って起動するとインストール中13%とかで全然進まない

じーっとみてたらスペシャルあなたになろうみたいなシュールビデオが流れ始めた

めっちゃ長い

眠くなってきたから横になってビデオみてたら電気つけっぱで寝ちゃってた

朝起きたらアプリケーションエラーおきててインストールできてねーし・・・

なんだよこれ

しらべたらベセスダってえらー おおいのね

はじめて買うけど

セスダってなんとなく東京問いボックスのソリダスとかぶるんだよなー

2017-06-14

新人がすでに残業してるんだけど

新人研修課題(Webアプリケーション作成)で遅れが出てるから残業してるんだけど、

冷静に考えたらおかしい気がする・・・・?

基本参考書与えて放置だし















・・・・・・・・・・・・いや、別におかしくないか

仕事しよ

2017-05-28

rails5.1から標準になっているpumaって本番に使えそう?

cruby を使っているならunicornにしてください。

crubyには、GVLがあるのでスレッドで動くアプリケーションサーバは、worker数を増やしたところで一定より性能は向上しないと思うんだよね。だってWEBアプリケーションってCPUバインドだもん。

アプリケーションDB以外へのIOでリソースを食っているなら設計見直したほうがいいし、最悪pumaを使ってください。

ちなみに開発環境pumaが標準になっているのは、webrickと比べて静的ファイル配信がはやく終わるからなんだよ。間違っても本番環境pumaを推奨している訳じゃないからね。

ちなみにheroku場合は、フロントwebサーバを配置できないので、スロークライアントunicorn workerを取られるくらいならpumaします、という覚悟必要

2017-05-01

出向先の人が優しくて仕事辞めたい

仕事内容を簡単に言うと、そこでずっと使われているアプリケーション保守改善機能追加)で、そのアプリの開発統合環境を私は知らないけれども、そこも教えていくので一緒にやりましょうというもの

業務自体は1日8時間で、残業もなくやらせてもらってる。(実際ものを覚えても残業は少ないみたい)

出向先になる職場の人も優しくて分からない点は教えてくれるし、興味があればでスポーツFPSの誘いもあって、それに乗らなければならないというわけでもない。


何が問題かといえば、手取りが15しかないこと。(ボナは0.5ヶ月)

出向先の方が2~300万クラスの車乗ってて「車持たないと不便じゃない?」と言われたり、スポーツも金のかかるスポーツを誘われたりして生活レベルに差を感じる。

正直私もスポーツゴルフとか)したいし車も持ちたいとは思うけれども、それをしたらもう貯金はできないよね。

大企業から受注を受けている会社派遣で入る社員。つまりは出向SEだが、ここで頑張っても給料増える気がしない。40代になっても手取り20超えないのではないかと思ってしまう。(いくらなら妥当なのだろう?)


何より嫌いなのが今ここで奴隷の鎖自慢をしている私である

奴隷の鎖自慢は駄目だろう。もうそれをした時点で辞めたほうが無難ではないか


P.S. 確かにVBをやると聞いて了承したが、VB6.0とは聞いてない。

http://anond.hatelabo.jp/20170501162003

そんなわけねー。何使ってるのか知らんが少なくともchrome, safari, firefoxあたりなら無限に食う。

アプリケーションメモリ使用量をユーザコントロールできないのはけしからんとか言ってemacsweb見てるようなインターネット老人の場合は確かに64GBのメモリ不要だ。pentium 3で17インチディスプレイあたりの時代に帰ってくれ。

2017-04-30

SIerプログラマーとして働いているがモチベーションが上がらない

訳あって、某SIerプログラマーとして働いている。

去年の夏ぐらいから新たなプロジェクトがあり、そこに参加しているのだけどいまいちモチベーションが上がらない。

原因の一つは、タスク管理がうまくできてないからだと思う。

タスク管理方法としては、毎度おなじみのExcelをつかって、日々の進捗を共有のファイルに書き込んでいくというものだ。

別にExcelを使っている企業なんて山ほどあるだろうし、とりわけそこに突っ込む気はないのだけど、

Excel管理されたタスクを見て、「今日も一日頑張るぞい!」という気持ちになるのは難しいものだ。

また、タスク粒度も大味なのも問題だ。

今のプロジェクトではWebアプリケーションの開発をしているのだけど、その画面ごとに1機能として管理している。

1画面1機能なので、どれだけ複雑な機能でも、それが1画面に収まっていれば1機能なのだ

さらに日々の進捗としても、その1機能に対し何%進んでいるか、といったアバウトな感覚管理されており、

まあ、こんなものかというどんぶり勘定を日々報告することになる。

PMも本当に仕様理解しているのか怪しいところがあって、日々の報告で多少進捗を盛っても気づかない。

周りの開発者は薄々感づいているかもしれないが、特に指摘が入るわけでもない。

こんな状況なので、プロジェクト開始時点ではMAXだったモチベも日に日に下がり、

今では、とりあえず動くものができればいいだろ的なまでになっている。

SIerというものはどこもこんな感じなのだろうか?

だとしたら、業界全体でデスマーチが横行するのも致し方ない気がする。

2017-04-23

http://anond.hatelabo.jp/20170423213123

Windowなら

★ スクリーンショットScreen shotだっけ。

https://www.sony.jp/support/vaio/beginner/dialogue/068.html >初心者向けの情報なんだねー

★ OSでalt + tabアプリケーションの切り替え

★ Excelを使うときには。F2文字入力になる。

★ オフィス使うなら、複製で control + D かな。他に、ショートカットコピペ以外の終了とか、閉じるとかでも積極的に使うようにすることかな。

 

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2017-04-19

Webサービス技術的な競争優位性なんて生まれるのか?

ベンチャーキャピタルしてます。昔からずーっと疑問だったが、Webサービス技術的な優位性なんてある?

たまに「うちのサービスアルゴリズムが凄いんです!!!」とアピールしてくる会社がある。私はエンジニアではないし、コーディングもしたことないから、その凄いアルゴリズムを正確に評価ができない。

でも、サービスにとって重要なのは、そのサービスがどうやって動いているかというよりは、お客さんがその体験を通じてどう思ったかのほうじゃないのかな。Webサービスアプリ含めて)なんて、クライアントアプリケーションサーバーの組み合わせでしかいから、簡単模倣できるんじゃないの(適当)?事実、そういう戦略を取っている会社はいっぱいあるし、そもそも日本ベンチャーアメリカスタートアップ模倣が多い。

からサービス競争優位性があるとしたら、技術のものによるものではなく、新しい技術を取り込んで顧客体験還元できる組織風土組織体制だったり、既存システム改善改良を続けるスピード感だったり、そういう単純比較が難しいところじゃないかなと思っている。となると、前述のアルゴリズム凄いアピールは、よくわかっていない投資家を騙くらかそうとしているか、単純に本気でアルゴリズムの優位性を信じているか、どちらかということになる。私はひねくれているので、前者だろうと思って「うちのアルゴリズムは凄いんです」はほとんど評価してこなかった(評価できなかったんだけど)。

実際ものづくりしている人たちから見ると、この見方は腹たっちゃうのかしら。

2017-04-05

初めて行ったIT系会社が衝撃的だった話

4行にまとめました

コミュニケーションが少ない

パソコンヤバイ

・他にも色々ヤバイ

・他のIT会社はどんな感じなのか教えて欲しい

他のIT会社がこんな感じと違っていたら申し訳ないです。それと読みづらかったらすみません

当方19歳。お金をもらいながらスキルの得られる「有給インターン」に申し込みました。

から書くのはそこでの話です。

IT系バイトは基本実務経験がないと受けられないので、僕は「未経験歓迎」というところを探していました。

大阪は都会といえど、東京の1/4程度しかIT系求人はありません。

そこは未経験歓迎で、土日もやっているところでした。

早速応募して、いざ面接履歴書書いているときや、会社に行くまではすごく緊張しました。

そして面接が始まったのですが、なぜここを受けたのか、やりたい業種は何か。という話になり、話の感じからもう入って何かをするテイで進んでいるのだと思いました。

ありがたいことに、トントン拍子で採用され、数日後から勤務することになりました。

サイトで書かれていた、”研修期間あり”がここで完全無給だと知らされたのは引っかかりましたが…)

それからしばらく経ち、会社に行って挨拶をし、何かすることはないかパソコンパスワードすら知らない状態なので)聞きました。

挨拶への反応も、業務に関しての回答もないので戸惑いましたが、社員さんにパスを打ってもらい、ログインしました。

ここまで数分の出来事ですが、アルバイトで見てきた他の業種とは雰囲気が違うな と思いました。他の会社よりコミュニケーションが控えめな印象でした。

それから何をすれば良いのか社員さんに訪ねたのですが、それはSkypeで話すとのことでした。

本来送るべき内容のメール送信を忘れていたのか、そこでSkype登録と、登録に使う会社用のメールアドレスを送っていただけました。

先程ログインしてもらったパソコンを使い、Skype登録をしようとしたのですが、ここでかなり記憶に残る出来事がありました。


パソコンクラック(?)されているのです。

クラックされているのか、定かじゃないのですが、少なくともライセンス認証されていなくて、あのデスクトップの背景が真っ黒のやつでした。

気になって、コントロールパネルからOSは何なのか見たのですが、Windows7のUltimateでした。

僕はPCを組んだことはありますが、OSのこだわりはないので、一番安いHOMEにしていました。会社パソコン事情はわからないのですが、一般的IT会社はUltimateを始め、HOME以上のエディションを使うのでしょうか?


面接の時に、「在宅でできるから、やれるなら在宅が良いよ」と言われたのを思い出しました。社員さんの理由は、「パソコンが古い」だったので、7を見たとき新しいじゃんと思いました。

僕は実際に相談して、作業の流れが把握できたほうがよいので本社で初めは仕事をしようとしたのですが……

本社での作業オススメされない理由は他にもありました。

アカウント作成しようと思い、デスクトップにあるブラウザーを使いました。

Chromeは開発用に使われているのか、ショートカット名前がイジられているので使いませんでした。そして、IEアイコンからしてめっちゃ古いので、不具合を避けるためにやめました。

他にあったのが、FireFox。それを使いました。

開いた瞬間ビックリしました。

アドウェア汚染されています

もう使いものにならないです。動いてるアプリケーションFireFoxぐらい。通知センターなどを見てもIMEすら切られているのか、漢字も打てない。

Pentiumで、RAMGBでも関係ないぐらい重い。

開いた瞬間、アジア系無修正ビデオの画面が別ウインドウで出るのは、控えめに言って泣きそうでした。

自分もこういう汚染経験があったので、ショートカットプロパティを開き、追加で書かれているURLなどを削除しました。開発で使っていたら申し訳ないのですが、凄い重かったのでごめんなさい。

Skype登録し、それでチャットを始めるのですが、IMEが効いてないのでひらがなをで検索してメモ帳を駆使して、半ば怪文書を作る形で連絡を取ることになりました。

社員さんに「個チャはやめて」と、グループの方へ回されました。

そこで挨拶をして自分の素性を話し、送られてきたDropboxファイルを見ながら作業しました。

というのも、会社サイト登録するのです。そこに登録するメアドを書いてたらニコニコ動画広告や、DMM広告に飛ばされることが多々あり、悲しくなりました。

自分プロフィールを書くと本登録ができるのですが、そのときにされるとマジで死にたくなります

そもそもメアドを送って仮登録した返信メールが、迷惑メールに送り込まれているところが面白かったです。探すのに10分かかりました。

課題をもらって、それを達成していくのですが、課題を保存するためのクラウドはどうするのだろう?というのが今でもずっと心に残っています

配布されたメアド登録するのは良いものの、メールボックスが開けないので認証ができません。

こんなに重いので、Dropboxテキストを読むのですら大変で作業なんてできる状況じゃありませんでした。

働く時間自分で決めれるので、早めに切り上げました。

次の日から在宅をしようと、配布されたメアドで自宅のパソコンSkypeログインしようとしたのですが、エラーで入れません。

調べたら、迷惑メールの送りすぎか何かでメールアカウントが凍結されたそうです。


そのまま今に至るのですが、どうすりゃ良いんだろう。。

IT業界がこんな感じ、というなら夢半ばで他の道を探すしか無いし、働けないにしても「作りたいものがないから、プログラミング勉強できない」という自分のために課題を出してもらった以上、それは達成してみたかったです。

友達にもこの会社を勧めたのが申し訳ないし、連絡が有耶無耶社員さんにも申し訳ない。

他のIT会社、みなさんが働いている会社はどんな感じなのか、教えていただければ幸いです。

2017-04-04

プログラマとして就職するときの後悔

私は地方情報専門学校の生徒です。

今年度卒業予定であり就活手前ですが、今まで何もしてこなかった自分への苛立ちと後悔を感じています。なぜそんなことになったのかを自分の気晴らしに書きます

今までやってきたことが足りなかった

専門学校入学するのは「プログラマになるための最短ルート」だと思い、学費大学より安いことから専門学校入学。前年度は学校では基本情報技術者勉強をするだけ。基本情報技術者を無事取得しましたがプログラミングの授業はゼロに等しかったので、個人企業apiajaxを利用した簡易的なwebアプリケーションを作ったりしました。

今年度に入り学科就活解禁日より二足ほど早く、プログラミングスキルを判定できる新卒エンジニア向け就活サイト大企業様のスカウトを受け採用試験に挑戦。結果は不採用で通知メールにはコミュニケーション問題なかったが、技術力が足りないと書かれていました。

私はCentOS多目的サーバ高校時代から運用し、webアプリケーションを作った経験国家資格をもあれば十分だろうと思っていたことが甘かったと痛感。

面接(というより面談)の対応をしてくださった方はとても良い方で、面談の中でエンジニアは常に最新技術へのアンテナを貼るべきで学生のうちは何でも作ってみるべきだと教えてくれました。

その教え通り私は今何かを作ろうとしています。それでも自分の中でプライベート時間プログラミングに割くことができず娯楽に使ってしまう心の弱さに苛立ちを感じているのです。

何とかしてプログラムを完成させ、社内開発の会社に入りたい…そう思いながら今日も生きます

ちなみに学校斡旋する企業はどこも社員数30名以下の下請け人材派遣会社なので自分リクナビ等使って探しています

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