「html」を含む日記 RSS

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

2017-05-23

いちいち興信所的なものを使って、出会人間について全ての人間関係を洗い出す

ベトナム人里子が81人いる杉良太郎から芋づる式に

://tokumei10.blogspot.jp/2014/11/81.html

例えばこんな感じで調べ上げるのは富裕層でもない限り出来ないけどね

急募リテラシーに自信のある村民

最近はてブトップページブログ日記人気エントリーのところに

サラリーマン大家太陽光発電日記

http://taiyoukou-salaryooya.seesaa.net/

かいうのが出まくってるんだけれども、こいつを見てくれ、こいつをどう思う

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/450056761.html

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/449848113.html

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/449848097.html

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/449848030.html

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/449848015.html

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/449847991.html

ttp://b.hatena.ne.jp/entry/taiyoukou-salaryooya.seesaa.net/article/449672422.html

単純に発電量が書いてあるだけのエントリが軒並み10から20ブクマっておかしかないか

リテラシーに自信のある村民判断を伺いたい

なおそれ以外のエントリを見てみたところ

電気トラック向け急速充電器・太陽光電力も活用 三菱ふそう: サラリーマン大家太陽光発電日記

http://taiyoukou-salaryooya.seesaa.net/article/450064879.html

先日、三菱ふそう川崎工場電気トラック向け急速充電器、太陽光電力も活用、との記事が出てました。このようなインフラが整備されていくといいですよね。

と書いて、以下、日経記事をまるまる転載しているだけの模様

ちなみに日経サイトを見てみたところ

Webサイトへの記事全文掲載は、原則としてご遠慮いただいております

サイトへの雑誌記事掲載をご希望場合には、閲覧回数/閲覧期間を限定した上で弊社サーバー上の記事PDFを閲覧できる有料のサービスをご紹介いたします。

http://ec.nikkeibp.co.jp/QA/html/qa_18_2.html

夢の国天然ガス資源メタンハイドレート」 4年ぶりにガス産出に成功

http://taiyoukou-salaryooya.seesaa.net/article/450064435.html

こちらはitmedia記事転載日経場合と違って丸々というわけではないが、引用要件は満たさないのではないか

このあたりについてもリテラシーに自信のある村民判断を伺いたい

最後に、集まってくれたリテラシーに自信のある村民にもう一つ聞きたい


















ブクマメタブ等々でおかしいのではないかと指摘してる村民が見当たらないんだが、君ら一体どこにいたの

2017-05-21

>米中露同盟

こういう構図だと日本って分割統治消滅しかないわな

://tokumei10.blogspot.jp/2017/05/blog-post_72.html

2017-05-19

電波陰謀論サイトってときどきまともな事を書くから、ただの精神病者とは思えないんだよね

米軍北朝鮮攻撃と同時に中国軍尖閣上陸したらどうするんでせうか?

://tokumei10.blogspot.jp/2017/05/blog-post_63.html

2017-05-16

Benefit-OneUXがクソすぎる

https://bs.benefit-one.co.jp という福利厚生提供するWebsiteのUXがクソすぎる。

こんなサービスでどうやって福利厚生受けるんだよ。まじでクソすぎてアプリ開きたくない。

どうしてこんなクソ開発会社が今時生き残れるの?こんなのに自分会社が金払ってると思うと悲しくなる。

福利厚生受けたいのに逆にストレスでブチ切れそう。

この稚拙設計デザイン個人情報をセキュアに保てているのかまじで不安。開発できる能力がないと思うから他の責任者か開発会社委託するのが良い。まずはUXサービスデザイン専門家とかコンサルレビューしてもらうのが先か…

2017-05-15

http://anond.hatelabo.jp/20170515130428

いざ何か(たいていはHTML)に変換するときオリジナルだと面倒なので適当マークダウン言語を使うといい
最初おすすめはそのものずばりMarkdown

http://www.markdown.jp/what-is-markdown/

できあがった文書があるのならMarkdown表示アプリで小綺麗に表示させれば見栄えもいい(HTMLWebブラウザ関係に同じ)
多くのモダンエディタ組み込みMarkdownの書式をサポートしているから書きやすかろう


そういうの抜きでいいなら中黒「・」かな
日本語変換中のキーボードから一発なのがいい

2017-05-13

無職だけどプログラミング覚えたい

ハロワ行くと職業訓練プログラミングもあるんだけど

どの言語就職につながりやすいだろうか

おすすめを教えてほしい

こないだ見てたらJavaとかCとかPHPとかあった

こちらのスキルとしては

プログラミングに関しては子供の頃ベーマガ見ながらBASICやったくらいの記憶しかない

すなわちおっさん

あとプログラミング言語じゃないけどHTMLCSS自分ホームページつくったりするくらいにはできる

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-05-10

【追記あり】Re: inside 売れないサービスの開発現場から

http://anond.hatelabo.jp/20170509183828

を書いた増田です。

こんなにたくさん反応があると思っていませんでした。

開発に対してモチベーションが保てずに、愚痴まとめてスッキリしようとか、そういう気持ちで殴り書いたものだったので。

本当にありがとうございます

「俺、こんなんドン・キホーテと一緒やん」みたいな気持ちでやってたことが、少し報われました。

自分発信のものに反応もらえるってこんなに嬉しいんですね。(何しろ二年くらいそういうのないもので。)

はてブツイッターでの反応は全部読んでますありがとうございます。(二年なかったので許してください。気持ち悪がらないでください。)

どうせお前のスキル不足だろ!!!バカ!!!働け!!!死ね!!!みたいなの予想してたので、9割くらいの人に同調されてるのに少しびっくりしています

と同時に、そんなんやっぱりどっか根本的におかしいよね、なんて思ったりもしています。大きい問題すぎてどうにもできないですが。ちなみにスキル不足はあっています

いくつかちょっと返したいコメントあったので、ざっくり返信します。

ーーーーーーーーーーーーーーーーーーーーーー

・「給料もらってるの?会社大丈夫?」

一応お給料はいただいてます。少ないですが。僕は業務委託なので、会社大丈夫かどうかはあまり興味がないのでよくわかりません。潰れたら次に行くだけです。

・「お金出所がきになる。」

あんまり詳しいことは言えませんしわかりませんが、受託開発みたいなことをしているようなので裏で黒いことをしていない限りは、そこで得た収入をつぎ込んでいるのだと思います。今の体制を維持していくだけなら会社的にはそんなに負担になっていないのかもしれません。プロっぽい人が一人もいないので、実験的な意味合いもあるのかなあと勝手に思っています

・「辞めればいいのに」

おっしゃる通り。だけど僕が抜けたらもうこのサービス動かなくなってしまます。一回やるって言って、お金もらっている以上は続けたいじゃないですか、できるだけ。一応愛着も二ミリくらいあります。でも、お給料出なくなったら秒でやめますよ。

・「仕様決めには入らないの?」

この話聞きます

~~~~~~~~~~

ディ「やっぱり仕様決めるのに作る人がいないと進まないよね!」

僕「そうですね。」

ディ「まず、今回はこういう機能を入れたくて、この機能が狙っている効果としてはね・・・」(クソでかいビジョン説明Google行け。)

僕「なんとなく伝わりました。で、どういうの作りたいんですか?」

ディ「こうこうこんな感じで、〇〇(ちょっと話題スタートアップサービス)みたいな、ユーザーが楽しんで使ってくれる機能いいね!

僕「なるほど。まず、それもう別サービスでやったほうがよくないですか?今までの方向性から変わりすぎなような。あんまり詰め込むとユーザーわかんないですよ。」

ディ「大丈夫!後から説明する!もうストーリーはできてるから!そしてそれはデザイン次第だから!」

僕「わかりました。後ここ、なんか聞いてたビジョンとずれてるようなんですけど。」

ディ「そこはねーこうこうこういう理由でね、こうなってこう、さっきの説明もしちゃうけど、ここからこうなるストーリーを狙ってるんだよ」(ユーザーにその説明する気なのかな?)

僕「なるほどですね。じゃあ、全体的にこういう仕様にしたほうがよくないですか?そんなにビジョンからずれてもないですし。」

ディ「うーん・・・それだとなあ、なんか違うんだよな。」

僕「こっちの方が技術的なこういう問題も解消できますよ。ちょっと初めのだとすぐ実装思い浮かばないですし、バグも出やすそうです。」

ディ「でも可能不可能かでいうと、不可能じゃないよね?」

僕「不可能ではないと思いますけど。」

ディ「じゃあ、こっちでいこう!!!!」

僕「わかりました。」

ディ「で、どれくらいでできるかな?」

僕「え、まだ方向性だけで、何にも決まってないのと同じなので見積もりはできないですよ。」

ディ「そのために呼んだのに!!!!!」

~~~~~数時間後~~~~~

僕「ここはどうするつもりですか?僕はA案の方がいいと思いますけど。B案ちょっと影響大きすぎますし。」

ディ「でもB案もなあ・・・B案じゃないとストーリーがなあ・・・」(この仕様会議中にもう五回はそのストーリー外れてるよね?)

僕「(こうなると進まないので)じゃあB案で。」

ディ「お願い!!!!」

~~~~~数時間後~~~~~

ディ「ここはキモ!本当にキモ!コアだから!!!

僕「なるほど、でもこの機能ユーザーいないと楽しめないですよね?こうこうこうしたら、いいんじゃないですかね?」

ディ「絶対増えるから!この機能いれたら絶対増える!!!!」

僕「いや、というか、ストーリー自体ユーザーいないと途中でこけて、ケアできてないこといっぱいあると思うので、コアならなおさらちょっと考え直した方が。」

ディ「・・・・・・・・(キレ気味に)じゃあどうするの?全部無駄になるよ?」(ご愛顧ありがとうございましたってhtmlならすぐ書けるよ?)

~~~~~~~~~~

こんな感じですぐスリーパーホールドで固められちゃうんで、無駄なんです。

・「今どきPDFで納品とかあるの?」

僕も驚いています。何度か無理って突き返したんですけど、他のツールでも手間があんまり変わらなかった(すごい話し合うくせに実際見て大幅に手直しがある。)

ので、もうPDFで仮組みした方が早いと思って諦めてます。紙出身なんじゃないの?って意見見て、なるほど、と納得しました。

ーーーーーーーーーーーーーーーーーーーーーー

なんかいっぱい書きたいことあったんですが、忘れちゃいました。

辻褄があってない部分は、本当のこと書きすぎてて、ちょこちょこ誇張入れたり省いたり、言えないことをごまかしたり、分かりにくいなとおもったところを直したりしたためです。単純にミスってるとかもあるかもなので、雰囲気で読んで下さい。ミス錯乱に変える高等テクニックだと思って褒めてくれてもこちらとしては何の問題もありません。褒めて。

ちなみにディレクターは二人居ますが、もう片方はほとんど言いなりなので、ここに書いているやり取りは、一人のディレクターしか出てきていません。

こんなうつの上がらないエンジニアの戯言、何の先の展開力もない、ただの文字だけのコンテンツが、2日で600はてブ以上取って、ほんとうにインターネットすごい。

もっと正直に話すと、最近鬱手前っぽい症状が出ていて(一回なったことがあるので)、ちょっとやばいと思ったので、書きました。

本当に激務でもなく、パワハラもない、これ以外のストレスはないホワイト現場なんですが、こういうことでも積み重ねていくと滅入っていくんだ、と自分でもちょっとびっくりしています

また溜まったり、状況が変わったら(転職とか転職とか転職とか)書きます。本当は漫画にしたいと思っていたのですが、下手すぎて文章しました。誰か漫画にしてください(強欲)。

ではでは

console.log("thank you for reading!!");

~~~~~追記~~~~~

作業が待ちに入って、少し手が空いたので追記します。

続編も思ったより伸びてしまいました。20はてブくらいで尻すぼむだろうと思っていたので。

本当にありがとうございます

そしてみなさんご心配ありがとうございます

一度壊れているからか、自然

・ねる

やす

・てきとうなことをいう

・むしする

と、危ない時には四つの技を覚えましたので、戦闘では全く使えませんが、自己防衛にはまあまあ長けたポケモンになっていますので心配いりません。

文読みやすいとかうまいとか、言われ慣れてないので困惑していますありがとうございます

書くこと自体は割と好きな方なので、これくらいの脊髄反射みたいなものでよければ、シリーズ化とまではいきませんが、書き続けたいなと思っています

増田として書くのも気楽で楽しいんですが、別サービスへの移行も考え中です。まとめるとき楽そうなので。でも、こういうのって増田からいいんですかね?

まりブログなど続いた覚えがないので、まだ思案中ですし、もう書けることも仕事系統だと同じテイストなっちゃうので、読み飽きるかなあとも思っています

やるとなったらある程度身を削る覚悟はいますが。

ではでは、もしかしたら増田としてはこれが最後かもしれません。

人には言えないドン引きされるような性の話が書きたくなったらまた来るかもしれません。

console.log("see you later!!!");

使ってみる

Hatelabo::AnonymousDiary

はてなはてラボはてな匿名ダイアリー


こういう遊びは好きだ

 1999年5月11日 14時34分



表示を変えると気分も変わる


 増田の見た目に飽き飽きしている?


 HTMLを貼り付ける。


 こんなふうに表示される


記事を読む

クロスブラウザ対応しろとか言う奴

あなた方のせいで私は今日もおうちに帰れないのです

Webサイトクロスブラウザ対応に携わったことがある者だけがIEに石を投げなさい

http://anond.hatelabo.jp/20170508211030

最初から追記(元増田がどういう環境でどういうソースから電子書籍を作ってるかわからないので、以下は自分のところの話)

新刊電子データなのだから電子書籍にするのも簡単だろとか言う方々はかつてのクロスブラウザ対応のことを考えてもらいたい。

HTML電子データなんだからIE6レイアウトが崩れないようにするなんて簡単だろ」って言ってんのと同じなんだよ。

InDesignEPUB書き出しは現状全く使えず、まともなEPUBを吐いてくれない。

となるとDTPの流し込み用テキストをもとに電子書籍データを作ることになる(そうじゃないところもあると思うが)。

もちろんInDesignから書き出したPDF電子書籍でございと売ればこの手間は省ける。

しかしリフローしない電子書籍文字を拡大するとページの一部しか読めなくなる電子書籍なんて読みたくないでしょ?

NHKテキストなんかはそれやってるけど。

印刷用のPDFデザイン簡素にして、Re:VIEWから直接出力できる程度の装飾しかしないなら話は簡単だ。

同じソースから紙の本向けのPDF電子書籍用のEPUBを同時に生成できる。

その場合でもIllustratorで作ったベクターデータの図を載せる場合PDF向けのEPSデータ(1色)とEPUB向けのPNGデータRGB)が必要だ。

そうなるとPDFEPUBで同じ場所にきちんと同じ図が掲載されているかのチェックが必須となる。

図に修正がかかった場合EPSPNGの両方を間違いなく修正たかチェックが必要

そんななので、紙のデータ電子書籍データをワンソースからサクッと作れる世界が来るまではもうちょっと時間がかかりそうなんだ。

2017-05-09

【追記あり】inside 売れないサービスの開発現場から

この二年間、ある一つの売れないサービスを開発し続けてきた。

GW実家に帰ったとき地元友達に話したら面白がってくれたのでちょっと書いてみようと思う。

今作っているアプリは、売れていない。

二年前に開発が始まって、リリースして一年半ほどになるが、一円も稼いでいない。

エンタメsnsのはずなんだが、アクティブユーザーが増えるはずの大型連休で、起動したユーザーがたったの三人だった日があるほど、売れていない。

売れてないが故に常駐しているエンジニアは僕一人だ。外部のエンジニアスポットでたまにタスクベースでお願いする程度。

ディレクターっぽい人が二人(マーケティング兼任)と、デザイナーが一人いて、

この3人と僕とのやりとりを地元の友人は面白がってくれた。

いわゆる「エンジニアあるある」ではあると思う。

例えば新機能の開発が始まったとき

ーーーーーーーーーーーーーーー

ディ「〇〇な機能が欲しいんだけど」(延々ぐらぐらのビジョン演説する。)

僕「ビジョンはだいたいわかったんですけど、どういう仕様にするつもりですか?」

ディ「ここはこう、Facebookみたいな感じで、Instagramのこういうのも入れたくて、twitterもやってるからこれも組み合わせたい。」(ふわっとした仕様で細かくは決まってない。)

僕「(俺一人でやるってことわかってる???納期はいつですか?」

ディ「一ヶ月後くらいにリリースしたいんだけど」

僕「細かい仕様が決まるのはいつですか?」

ディ「今週には決めるよ。」

僕「わかりました。待ってますね。」

~~~~数日後~~~~

ディ「できた、もう一人のディレクターと話し合ってすごいいいものができたよ、これは本当に売れるよ。大逆転できる。」(毎回言う。最初はなるほど、と思っていたが一年半言い続けられる神経が理解できない。)

僕「だいぶ変わってますね、初めの大まかな仕様と。」

ディ「そうなんだよ、ここはこうでここはこうで」(新しいぐらぐらのビジョン演説

僕「(まあいいか・・・)こことここは難しそうで時間かると思うんですけど、納期は一ヶ月後のままですか?」

ディ「マーケット戦略的にそこがデッドだね。」

僕「わかりました、これだけならなんとかやってみますデザインはもうあるんですよね?」

ディ「まだない、すごく重要機能で本当に今後を左右するからこだわりたい。」

僕「(こだわり・・・)わかりました。じゃあ一旦機能から作りますね。」

~~~~数日後~~~~

ディ「デザインできたよ、本当にこだわって作ったからね。デザイナーから受け取って」

デザ「どうぞ」(PDF渡される)

僕「・・・・・」(PDFだとダメって二億回くらい言うてるけど、耳がついてないんだな・・・sketch存在知ってるはずなんだけどな。)

~~~~数日後~~~~

僕「ここ、スマホだとデバイスによって幅変わるんで、こう直しておきましたよ。割合的にずれてないので、問題ないと思います。他のサービスもだいたいこうやってますんで。」

デザ「え、なんでですか?」

僕「スマホだとデバイスによって幅変わるんで。iphone5iphone6だと幅違うじゃないですか、解像度も違うじゃないですか。」

デザ「え?なんでですか?」

僕「え?なんでですか?」

~~~~数日後~~~~

デザ「レスポンシブデザインにしたいんですけど。」

僕「いいですよ。」

デザ「こんな感じで」

僕「レスポンシブデザインだと、html変えられないので、こういう全く違うのは難しいと思いますよ。」

デザ「え、なんでですか?やってるところありますよ。」

僕「え、だからhtml自体をいじれないので、PCSPもどちらもデザイン段階から考慮して作らないとダメなんですよ。それに言ってるサービスレスポンシブじゃないですよ。」

デザ「え、なんでですか?」

僕「え、なんでですか?」

~~~~数日後~~~~

ディ「どう?」

僕「大体できました。これで大体仕様通りだと思います。」

ディ「どれどれ?」

ディ「え?なんでこここうなってないの?これは?ここは?これ何?これこうなってないのなんで?」(本当にくだらないボタン位置とか、fontの微妙な大きさとか)

僕「え?仕様に書いてます?それに俺それ確認してあなた納得してましたよね?それにPDFだとこれが限界です。」

ディ「うーん、大問題だぞこれは・・・」(一円も売り上げてないサービスで大問題とか起こりえないでしょ?)

~~~~数日後~~~~

ディ「昨日考えたんだけど、やっぱりこの機能、こうなるべきだと思うんだよね。」(根本から覆す意見を振りかざす。)

僕「え、明日リリースですよね?もうそのつもりなんですけど。その修正リリース後じゃダメなんですか?」

ディ「大丈夫だよ、本当に簡単修正で終わるだけだから。二時間だよね?このくらい」(簡単修正なんて、中身知らないお前がどうして言える。)

僕「いや、このレベルだと、作り直しですね。」

ディ「え?なんで?だってここチョロっと直すだけだよ?」

僕「ご存知ないかもしれませんが、あなたが途中で細かく仕様変更されたのに対応した際、説明したはずです。こことここは相関関係があるので、影響的には全部ですよ。」

ディ「なんでそんな実装になってんだよ!!!」(なんでそんな仕様にしたんですか?)

~~~~数日後~~~~

ディ「ここのこの仕様なんだけど、どうなってる?」

僕「そこはこうなってますね、どうしたんですか?」

ディ「そこ、やっぱりユーザーフレンドリーじゃないと思うんだよね、こう変更して」(中身が複雑で聞いた端から忘れるレベルユーザーフレンドリーとは。)

ディ「シンプルイズベスト!だからね。」

僕「もう僕がわからないんですけど、それ大丈夫ですか?」

~~~~数日後~~~~

ディ「あの、前にユーザーフレンドリーにしようって変更したところだけど。」

僕「はい問題ありました?」

ディ「ここの仕様ってこうだったっけ?」

僕「いや、そこはこうで、こことこことここと関係しているのでこうなっていて、コードレベルだとこんな感じですね。別のところにも影響あるのでそこもこう直してあります。」

ディ「え?そんな仕様だったっけ?」(ユーザーフレンドリーとは。シンプルイズベストとは。)

~~~~リリース後~~~~

ディ「お疲れ様ー。」

僕「お疲れ様でした。」

ディ「だいぶ遅れちゃったけど、なんとかリリースできたね。やりたいことの10%くらいしか実現できなかったけど。」(何作ろうと思ってるんだ。国か。)

僕「そうですね^^」

ーーーーーーーーーーーーーーー

もちろん売れているサービスも売れてないサービスも、同じような現場なのだとは思う。

ただレベルが違うだけで。

僕も全く優秀なエンジニアではないから、スキル不足の面も大きいのだと思う。

しかし本当に他の三人がwebというものを知らなすぎる。

これで全く売れないのだから、報われるところがほとんどない。

これがいつまで続くのか、という不安となんでも経験だろ、と突っ込んでしまった後悔しか残っていない。

~~~~~~追記~~~~~~

仕事の合間にみたら思ったより拡散されているので、ちょっと困惑しています

なのでちょっと言い訳というか、補足というか。

多少の誇張とごまかしはもちろんあります特定を避けるためです。

そして何より、これは半人前エンジニアの僕から見たものです。

ディレクター側の人の意見無視しています

そして、現状に対してキレているわけでもどうにかしたいと思っているわけではないです。

あ、これを書いた昨日は相当キレていましたが。

これらのことはだいたい普通だと捉えています人間のすることですし。プロジェクトは期間が長いですから、変化が当たり前です。変化の仕方が変なだけで。

エンジニアは発信する文化があるので、結構他のエントリでも読めますが、もっといろんな業界の人の専門職バージョンを読みたいので、見ている人がいれば、ぜひ投稿してください。

まだ溜まってることあるので、近いうちに続編書きます

最後に、胃が痛くなった人、古傷が痛んでしまった人、思い出したくないこと思い出させてしまった人、申し訳ありません。

同じような境遇で戦っている同士に捧げます

~~~~~~追記2~~~~~~

続編書きました。いくつか反応に返信させていただきました。

http://anond.hatelabo.jp/20170510224801

2017-05-06

C#リッチツールチップ使いたいときは、自作(もしくはアドオンインストール)しなきゃだめなの?

標準でできないの?

せめて、HTMLとかで書きたいんだが?

2017-05-03

はちまデビューした増田トラバ民さんおめでとうございます

皆様が精魂込めて書いた文章はちま様が吸い上げて自分のものしました。

p://blog.esuteru.com/archives/20012990.html

お前らそれでいいのか?

http://anond.hatelabo.jp/20170502165004

はてブページが「危険サイト」扱いになる件

Norton

危険Web サイト遮断しました

アクセスしようとしたページ:

http://b.hatena.ne.jp/entry/**********.html

これは既知の危険Web サイトです。このサイトを表示しないことをお勧めします。 詳細レポート でこのサイトセキュリティリスク説明します。

保護のために Web ページを遮断しました。 Symantec を参照してください。

[このサイトを終了する]

この Web ページを表示できます

と表示する。

はてブページにたどり着くには「このWebページを表示できます」というリンクをいちいちクリックしないとならない。

で、「詳細レポート」をみると、「ID情報の脅威:1」となっている。

「脅威レポート」では「フィッシング攻撃 みつかった脅威:1」である

なんとかしれください

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

http://anond.hatelabo.jp/20170501041533

レスポンスヘッダー抜粋

Cache-Control:no-store, no-cache, must-revalidate

Connection:keep-alive

Content-Encoding:gzip

Content-Type:text/html; charset=UTF-8

Pragma:no-cache

Server:cloudflare-nginx

Set-Cookie:CAKEPHP=xxxx

X-Powered-By:PHP/7.0.18

2017-05-01

フロントエンドってHTMLとかCSSの事じゃないの?

http://anond.hatelabo.jp/20170501085956

何か知ってる単語一つも無いんだけど。

webサイトってHTMLとかCSSで書かれてるんじゃなかったの?

2017-04-29

低質な比較サイト問題

内閣府 公共料金審議会(第15回)

ttp://www.cao.go.jp/consumer/kabusoshiki/kokyoryokin/senmon/015/shiryou/index.html

資料1-1 p8より。

  1. 質が低い比較サイトの乱立
    1. 網羅性が低い
    2. 不正
    3. サイトコンテンツの無断流用
  2. 特定会社への利益誘導

消費者信用失墜

アフィリエイトサイトの多い、ウォーターサーバー化粧品などの比較サイトと同じ状況ですね。

2017-04-26

DeNAホテル連れ込み事件推定無罪原則は?

http://bunshun.jp/articles/-/2280

http://b.hatena.ne.jp/entry/bunshun.jp/articles/-/2280

ブコメ、まるでX氏が真犯人であることを確定で凄まじい勢いで叩いている。

推定無罪原則は?

推定無罪原則ってちゃんと常識として共有されてるんだろうか

http://mubou.seesaa.net/article/449111781.html




おもっきし真逆ブコメしてるクズもいるし

http://fut573.com/compare/?url1=http%3A%2F%2Fbunshun.jp%2Farticles%2F-%2F2280&url2=http%3A%2F%2Fmubou.seesaa.net%2Farticle%2F449111781.html

http://fut573.com/compare/?url1=http%3A%2F%2Fbunshun.jp%2Farticles%2F-%2F2280&url2=https%3A%2F%2Fnews.yahoo.co.jp%2Fbyline%2Fshinodahiroyuki%2F20170422-00070193%2F

女子大生狂言かもしれんし、

実際行為はあったかもしれないが当時は完全同意女子大生が後で翻意したのかもしれない

ましてやこの訴え自体文字通り「週刊誌レベル」にすぎない

裁判もまだ始まっていないし、

何より肝心要のX氏側の弁明は一言もない

一方的女子大生当事者証言のみの不確定極まりない話

これでDeNA叩いてるバカどもって推定無罪とかどーでもいいってことですよね?

結局はてなで言われる推定無罪なんてダブスタにすぎない

自分に甘く他人に厳しい

ただそれだけ

偉そうなこと言ったって言った本人がまともに守りゃしないんだから

そりゃ世間はそんな言うこと聞くわけがねえ


くたびれはてこもひどかったなあ

言ってることが平気で正反対になる

それで平気なツラして社会正義を語る

ちゃんちゃらおかしいぜ

はてな正義は、所詮この程度

底が割れてるんだよ

2017-04-19

流行ってるOrarioと大学側について思うこと

Orarioについて思うこと

Orarioについて

現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、

ひとまずこの記事については、下記URLにある、京都大学専門家であらせられる記事について、一人歩きしてる感があるので、

もう少し彼のような上流側(という表現で良いかどうかは不明だが)の専門家ではなく、

下流プログラムガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。

  

https://srad.jp/~yasuoka/journal/611343/

  

  

不正アクセスという言葉曖昧

Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性安全性について』(2017年4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。

  

Orarioの特性安全性について、本当にスクレイピング技術クライアント端末側で行っているのであれば、

この部分は間違いではないと私(匿名で失礼)は考えている。

  

この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。

  

KULASISにずっと不正アクセスを繰り返していて

  

上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である

逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である

  

何せ、開発者勝手アカウントを使って入り込んで様々な検証を行う必要があるため、

学生からIDパスワードを借りたはずだ。

借りてログインするのが不正かというと微妙ラインだと思う。

  

この辺りにもやっぱり大学教授のいやらしさがあって

KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、

あくま大学側が定める規約規則から若干外れた使われ方がされているという意味不正アクセスである

  

法律的には、正直不正かどうか微妙ラインになる。

(そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない

  

開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大規約によれば、不正アクセスにあたるのかもしれない。

個人的には当たらないと感じるが。

  

  

現在動いているアプリ不正アクセスと断言できない

現在動いているもの不正アクセスではなく、

京大規定に定められたユーザが「特定ブラウジングツール(Orario)」により、

KULASISにアクセスしているのだからアクセスとしては不正ではない。

本当にスマートWebスクレイピングで行われているのであれば、Webブラウザと全く同じ動きをするはずで、

それを不正アクセス断罪してOrarioは不正というのは表現が汚いと考える。

  

  

これはコメント欄にもあるが、

https://srad.jp/comment/3196554

また、ChromeSafari(及びその他マイナーWebブラウザ)なども御校のWebサーバーよりコンテンツデータを取得し、HTML構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか?

  

ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。

それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、

Webブラウザ一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう

京大ユーザが開発に携わったか証明できない以上、彼にとっては不正なのかもしれないが、

ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。

  

  

アクセスパターンを公開できない理由とは?

他にもこの部分

Orarioアプリでは「Webオートメーション(Webスクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン(にインストールされているOrarioアプリ)に学生アカウント大学IDパスワード)を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要情報のみを取得し、Orarioアプリ時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています

全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ

  

この部分も怪しいものである

Webスクレイピング技術に関して、なぜアクセスパターン問題になるかが一つ疑問である

下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング切り貼り)している。

  

それをアクセスパターンを解析で一体何が取れるのか?という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。

  

もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティ観点上公開すべきではないだろうか、

逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである

  

ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから

アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、

学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である

学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。

  

そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、

現在すでにスクレイピング確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。

(ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……

(もちろん、アクセスログを見て、ログインページからWebスクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。

  

たとえKULASISが京都大学オリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。

同様に日立富士通も同じような大学教務事務パッケージがあるが、

基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、

本当だろうか?嘘を書くのもいい加減にしろ? と思う。

大学側について思うこと

なぜOrarioが学生に人気か

UIが糞(システムスマートフォン対応がノロい)だからアプリ流行るということに気づくべき。

  

富士通日立にしてもそうだが、API提供したほうがいいのではなかろうか。

とくにKULASISだったか何だったは、京都大学謹製と聞いている(違ったら失礼

少なくとも他の大学教務事務パッケージではなかったと記憶している。

であれば、京都大学API提供大学側で専門家を集めてOrarioを超えるものを作ってはどうか?

  

大学予算確保の問題

実際大学でこういうことをやろうにも、問題になってくるのは予算で。

大学は、縦割り構造で、横とのつながりが極端に薄く。

教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。

これが実に糞で。

つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。

  

その辺りが難しいのは知っているので文句は言えないものの、

ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。


まとめ

学生がアホ → 仕方が無い若いんだし

大学がアホ → 学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ

教授がアホ → 曖昧表現で、素人を先導しようとするのが見え見えで気に入らない

Orarioアホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ


以上です

2017-04-15

http://anond.hatelabo.jp/20170414142432

知ったかPHP語るなよ。一発勝負って、PHPの考え方の真逆じゃねえか。それはむしろJavaとかC++の考え方だろ。

PHPHTMLに埋め込んで手軽に表示確認できるんだからトライアンドエラー何度でも確認しながら作っていくもんだろ。

ひょっとしてコマンドラインスクリプトファイルを動くもんだと思ってないかお前?

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