「HTTP」を含む日記

data:text/html;base64,PG1ldGEvaHR0cC1lcXVpdj1yZWZyZXNoIGNvbnRlbnQ9MDt1cmw9aHR0cDovL2FkY2xpY2suZy5kb3VibGVjbGljay5uZXQvcGNzL2NsaWNrP2FkdXJsPWh0dHBzJTNBJTJGJTJGYmVzdHNhZHNzYWxlLmNvbSUyRnBhZ2UlMkYlM0YyVldJams1NmpRTDdiaEpWQ1YycGVVbjdMPg==

デコードしたらこうなった

Permalink | 記事への反応(0) | 15:47

2018-12-20

■

https://twitter.com/minatonosakana/status/1075340986811801606?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1075340986811801606&ref_url=http%3A%2F%2Fjin115.com%2Farchives%2F52242185.html

毎日のように自分が介護されていることが分からず、

これは、自己決定権や愚行権の侵害じゃないのかね。

後見の在り方の方が問題なんじゃないの。

Permalink | 記事への反応(0) | 12:53

2018-12-18

■（PHP）　phpMyAdminのセキュリティー

アドバイスどうもありがとうございます。

https://anond.hatelabo.jp/20181218231219

本番サーバには入れないでね

phpMyAdminのセキュリティーって、過去の事例を見ると、あまり高くないようですね？

phpmyadmin - phpMyAdminのセキュリティについて - スタック・オーバーフロー https://ja.stackoverflow.com/questions/42501/

この手の管理ツールはセキュリティ侵害を受けた場合のダメージが大きいので、インターネットからアクセスできないようにしておくのが基本です。特に phpMyAdminは過去に致命的な脆弱性が何度も発見されており、インターネットにさらして利用するには向いていません。任意コード実行可能な脆弱性の事例もあり、DB以外にもリスクがあります。
　
内部ネットワークからしかアクセス出来ないようにしておきましょう。レンタルサーバのようなインターネットに孤立したサーバであっても、VPNの経路を作りそちらからしかアクセス出来ないようにしておくようにした方がよいでしょう。
　
IPアドレスによる制限は次善策です。アクセス元のIPアドレスが固定されており他人と共有していないならそれなりに安全になります。
　
URLによる隠蔽は外部から攻撃可能な既知の脆弱性をスキャンするようなカジュアルなアタック避け程度にはなりますが、URLは何かと漏洩するものですので、一般にセキュリティ手法と見なされていません。
　
アクセス制限をした場合でも、認証は必ず設定する必要があります。例えばCSRFのような攻撃にはアクセス制限は無意味です。
　
phpMyAdminの認証とHTTP 認証のどちらを使う方がよいかは使ったことがないのでわかりませんが、HTTP 認証の場合 BASICではなくダイジェスト認証にしてください。BASIC 認証は（ほぼ）生で認証情報が流れますので使ってはいけません。(ブラウザで人が操作する場合以外にはBASIC 認証を使わざるを得ない場合もあります）

対応策

phpMyAdminはローカルの開発サーバーで使う。
本番サーバーのMySQLはメンテナンスのときだけ、Adminer.php等を使う。（使用前にコピーして、使用後は削除する）　もしくはMySQLのコマンドで操作する。

こんなかんじでしょうか？

Permalink | 記事への反応(0) | 23:25

2018-12-09

■anond:20181209225623

仮想マシンのネットワーク設定を確認してみる必要があるんですね。

とりあえずググりまくって、Ubuntuのネットワーク状態を調べる方法を試してみました。

ip address show

この結果を見ると、ポート番号8000が使われてないかんじでした。

これを常時開けておいて、HTTP アクセスがあったとき使うように設定する必要がありそうですね？

参考になりました。

どうもありがとうございました。

Permalink | 記事への反応(1) | 23:09

2018-12-03

■anond:20181203014823

ゆとりとかエモいとかどうでもいいからhttpなのが私、気になります！

Permalink | 記事への反応(0) | 01:52

2018-12-02

■[勉強]　Web プログラミングが面白いほどわかる本

みんなで一緒に勉強してみよう！

Web プログラミングが面白いほどわかる本環境構築から Webサービスの作成まで、はじめからていねいに (N高校のプログラミング 教育) 単行本 - 2018/6/22

吉村総一郎 (著)

https://www.amazon.co.jp/dp/4046023023/

https://www.kadokawa.co.jp/product/321712000860/

サーバーサイドの入門に最適な、Web プログラミングのテキストが登場!

Linuxでの環境構築から、Git・GitHubによるコード管理、Node.jsによるサーバーサイドのプログラミングが学べる!

インターネットで学ぶ話題の通信制学校「N高校」が展開する、プログラミング教育メソッドの大公開第2弾!

約1000人の高校生にWeb プログラミングを教えてきた名物講師が、入門者がつまずきやすいポイントを、ていねいに解説!

【本書の対象読者】

・環境構築で挫折した方

・サーバーサイドに挑戦したいと思っている方

・SIer から Web系への転職を考えている方

【本書の内容】

■Chapter1　Linuxの基本を身に付けよう

LinuxというOS

コンピューターの構成要素

コマンドでファイルを操作する

標準出力

viの使い方を学ぼう

■Chapter2　シェル プログラミングをやってみよう

シェルプログラミング

通信とネットワーク／サーバーとクライアント

HTTP 通信

通信をするボットの開発

■Chapter3　GitHubで始めるソーシャル コーディング

GitHubでWebサイトを公開する

イシュー管理とWikiによるドキュメント作成

GitとGitHub

GitHubへのpush

Gitのブランチ

ソーシャルコーディング

■Chapter4　Node.jsでプログラミングをやってみよう

Node.js

集計処理を行うプログラム

アルゴリズムの改善

ライブラリ

■Chapter5　Slackのボットを作ろう

Slackのボット開発

HubotとSlackアダプター

モジュール化された処理

ボットインタフェースとの連携

■Chapter6　HTTP サーバーを作ってみよう

同期I/Oと非同期I/O

例外処理

HTTP サーバー

「Web プログラミングが面白いほどわかる本」を出版させてもらいました

https://note.mu/sifue/n/n69fdeadc4612

この本の利用の想定としては、Web プログラミングでサーバーサイドにチャレンジしていきたい方や、システムインテグレーターとしてWeb プログラミングを知らずに仕事をしてきたシステムエンジニアの方が、Web プログラミングを学んで行くための下準備の知識を蓄えるために利用することを想定しています。
　
実際、N予備校のプログラミング入門コースは、Web 業界やWebを活用する企業の社内エンジニア研修のテキストとして利用して頂いている事例も増えており、本書の内容の学習を必要とされている場所は増えて来ていると感じています。

Permalink | 記事への反応(1) | 09:21

2018-11-28

■７年勤めたNTT 系列を退職して２年半が経過しました（ノンキャリア編）

２年半ほど経ちますが、空前のNTT 退職ブームなので便乗しちゃいます。

http://kumagi.hatenablog.com/entry/exit-from-ntt

https://satoshi.blogs.com/life/2018/11/ntt.html

https://anond.hatelabo.jp/20181127235600

はじめに

まず既知の通りNTT グループは社員数約２８万人と非常に大きな組織であり、その中で研究所はエリート中のエリートが就く位置にある。つまり上記の方達は警察でいえばキャリア組にあたる方達にあたる。以降キャリア組と呼ばせていただく。

一方で、私は地方のノンキャリア警察官のようなポジションにある子会社（大株主は研究所）出身なので、その分際でこのようなエントリーを書くのはおこがましいかもしれないが、

キャリア組層のエントリーなのに共感できる部分がとても多い上に、すでに [ 10年勤めたNTTを退職しました（無能編） https://anond.hatelabo.jp/20181126192228　]のようなノンキャリアそうな人（←失礼はご愛嬌）のエントリーもあったりしたのでちゃっかり便乗させてもらう。

蛇足

ノンキャリア組は特にこれといった能力がない。つまり身バレすると死ぬので増田に書く。
SIerやSES叩きが一時期流行っていたが、それらとは全く別のベクトルであると考えてほしい。個人的には SIer や SES にもいいところはあると思っている。

自己紹介

自分について

関東では名前"だけ"は知られている、超底辺私立大学出身。Fランではないというけど個人的にはFラン。実際アホは多かった。コラボ授業でも専門学校の人に数Iを教えられてる大学生とかね。
就活中に運良くNTT グループに内定。リーマンショックの爪痕がモロにあった中で就活に疲れ果てていたので会社のポジションもやりたいことも何も考えず名前だけで入社。親は喜んでた。
デー子とかプロパーとか線表とかNTT 用語は入社後に知ったくらいNTTについて何も知らなかった。gooってNTTがやってたんだ！
学生時代は趣味でMFCなどでWindows アプリを書いてVectorにクソアプリを登録してたので、コーディングに関してだけは土地勘はあった。手前味噌になるが新人時代は研究所（親会社）の同期にもC++とか教えてた。
実はデスクトップよりサーバー大好き。学生時代は中古のバッテリーが死んだPentium M ノート PCをサーバーにしてIRC サーバとか op25b食らうまでqmail立てたりとか。脅威はおかんの掃除機。

会社について

研究所からの仕事が多い。実際、研究所に長い間客先常駐したこともある。
幹部クラスは公社出身が多いので交換器やUNIXに詳しいおじいさんが多かった。あと学閥も東大卒がむっちゃ多い。他旧帝大とか。
子会社といえど社員だけで当時でも連結で１０００人を超えるほどいた組織なので、恐らく組織としては大きい方。
子会社といえど子会社があったりする。孫会社と言おう。孫会社なのに超優秀な人がいて初めは自尊心ガタガタになった。
会社の上下とプロジェクトのロールレベルは一致してない。孫会社の契約社員がPL、うちの院卒の先輩が画面キャプチャ担当だったり。（あれ会社分けなくてよくね？）

データとデー子もこんな感じなのだろうか。ぜひ知りたいものだ。

よかったところ

各種エントリーと重複するところもあるがご愛嬌。

いい人が多い

いい人の定義が難しいが、穏やかで真面目な人が多い。飲食店のバイト時代のように「ボケコラ○すぞ」なんていう上司はまずいない。
たまにチート級の有能な人がいる。知っている人では今でも有名OSS プロジェクトのコミッターやってたりとか。
たまにチート級の無能な人がいる。知っている人では開いてはいけないメールを毎回開く人とか。でもクビにも降格にも絶対にならないいいところ。
それ以外は可もなく不可もなく凡人。僕もその一人。思えば２－６－２の法則はよく出来ている。

超法令遵守

生産性を犠牲にしてでも守る。サービス残業なんてやると逆に上司に鬼のように怒られる。
有給消化率は部署にもよるがほぼ１００％。
退職後は非常に手厚い保証。嘱託社員のおじいちゃんによく自慢された。

金が腐るほどある

日本銀行が刷った万券の大半はここにあるんじゃないのってくらい金があるので研究所の設備、下請けへの発注規模、サーバー、試験機器などは超リッチ。新人でもそれらの高価な機器の操作や大規模なPJに携われる。
お金があるというのは、常に稼ぎ頭が必要ではないということなので、偉い人を納得させれば大抵のことは自由にやらせてくれる。上記のOSS コミッターとかは多分そうなんじゃないかな。

悪いところ≒退職 理由

給料が安い

実は上記エントリーのキャリア組の給料を知らなかったんだけども、そりゃエリートでその程度ならオイラたちノンキャリア組の給料が地方の郵便局と変わらないわけですよ。安い。
上記で金を持っていると書いたけども何故か社員には回ってこない。株はちょっとだけ買えるけどね。
四十の管理職で６５０万らしい。ゆ、夢がない。
福利厚生が下層になるにつれて下がっていく。うちは研究所より福利厚生は低く、勤務時間も少し長く、休暇数も少し少なかった。孫会社の人は都内勤務なのに社宅も住宅手当もないとか。まあこれは僕が学生時代勉強をサボったツケなのかもしれない。

できる人もできない人もすべて同じ待遇

いいところと言えるかもしれないけども、できる人にとってはいい環境ではない。
自分がいるときでもかなり改善はされてきてはいたけども、まだ根強く年功序列の意識があり、パフォーマンスが悪い人が年齢で出世したり、逆に非常によいパフォーマンスを発揮しても５年ほど最下位の等級だったり。
遅刻魔とか無断欠勤か社会人としてどうなのという人もクビにはならない。無論、そういう人のケツふきをしても給料も等級もあがらない。

独自のプロトコルが大好き

個人的にはオープン派だけど差別化のために企業独自もある程度はあってもいいとは思う。しかし、既に完成されたものを車輪の再発明で劣化コピーを量産したりすることも多々ありそれらは作業の意味が感じられず。

技術に興味がない人が多い

上記に優秀な人がいるとは書いたが、それ以上にそもそも情報通信技術に興味がない人がおおい。特に年令を重ねた層に多い。
上司が、その上司（＝上司の上司）に説明するのを嫌って、自分が知らない技術（実装テクニック）・ライブラリ・ツール類を導入したがらないことも多々あった。
上司「おい通信は暗号化されているのか？」ぼく「HTTPSなので大丈夫です！プロトコルもHTTPでしか通信しません！」偉い人「IPsecのルータを導入しろ。ポートも絞れ。」上司「了解です！！！」ぼく「・・・」　ちなみに社内ネットワーク内の話である。
ぼく「じぇっとぶれいん買ってクレメンス」リーダー「みんな今までみんなEclipseでやってきたんだ。あとIDEは揃えたほうがいい。え、ショートカットが不満？俺のEclipse コンフィグおすすめだから設定ファイルやるわ！」ぼく「」
ぼく「ログ多すぎ　Fluentdいれて集約しましょう！」リーダー「なにそれ、集約ならこれつかえ！SCPで拾ってくれるぞ！」　つ[syuuyaku.sh] ぼく「😂」

社内システムがう○こ

セキュリティ意識が高い裏返しでもあるけども、例外除いてPOSTメソッド全禁止はやりすぎ。
検索を除くGoogleサービス(Gmail,スプレッドシートなど)は開くだけで、即監視部隊から説明を求められる。
WindowsやIE前提の社内システムが多く、僕はマカーだけどもVMでWindowsの用意が必要だったり。当時のMacのメモリは今みたいに潤沢じゃないんですよ。

その他

今はベンチャー企業でガリガリコード書いている。ぶっちゃけると、やることいっぱいでしんどいけど前職に戻りたいか？と聞かれたら明確にNOといえる。
この上ないワガママを言うならば、歳をとって体力がなくなったらNTTのほうが働きやすい環境であるのは間違えない。
退職後に同僚から聞いた話だが、今はリモートワークやリフレッシュ休暇、プレミアムフライデーの導入などいろいろ変えようとはしているようである。
会社によってまた空気が異なるかもしれない。聞いた話ではグループ内でも全員スーツの会社と全員私服の会社とかあるとか。

総評

NTT はいいところ。エンジニアリングが好きでそれなりの報酬がほしい人以外には。

Permalink | 記事への反応(8) | 09:54

2018-11-20

■

DBを「デービー」っていうのは日立に限らず業界標準じゃないかな

HTTPを「エイチテーテーピー」っていうのは日立だけ

Permalink | 記事への反応(1) | 17:05

2018-10-29

■はてなブックマークのコメント フォームがhttps 対応してない件

ブクマ一覧とか読み取り専用ページがhttp なのはそれなりのポリシーがあるかと思ったら入力フォームが存在するURLもそうなのは流石にアウト。

何故やらないのか。流石におかしい。

Permalink | 記事への反応(0) | 16:01

2018-10-19

■

何でリテラ表示されてんだよぉ〜ブロックしただろぉ〜

httpsになったんですね

ブロックリストがhttpだったからすり抜けてきたか

Permalink | 記事への反応(0) | 18:41

2018-10-08

■ブクマカはやはりダブルスタンダードがひどすぎる

前略、同一の人のブクマコメントではないのは、無論認識済み。

「女性エンジニア少ない問題」を解決するために、機械学習で男性エンジニアを女性に変換するのはてブ
 http://b.hatena.ne.jp/entry/s/logmi.jp/294756

ROOTSYさんのツイート: "おれはキズナアイを見てじゅうぶんにポルノだと思う（後略）のはてブ
 http://b.hatena.ne.jp/entry/twitter.com/rootsy/status/1048329776497393668

・追記

そういや2つのページのはてブコメント比較するのあったよなぁ、と思い出したのでこっちも貼る。

http://fut573.com/compare/?url1=https%3A%2F%2Flogmi.jp%2F294756&url2=http%3A%2F%2Ftwitter.com%2Frootsy%2Fstatus%2F1048329776497393668

Permalink | 記事への反応(0) | 01:01

2018-09-22

■JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当にコメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意でセッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザーが

「これは、セッションハイジャックか・・・！？」

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ！」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークのリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字のkeyが生成された

解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

英数字大文字小文字で約60の時は10桁で20 万年と書いているが

現代の解析技術は20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20 文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッション IDを含めれば安全」に関する私見

師から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapi サーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく

そのためapi サーバで上記前提で用いた場合に考えたことを書く

web アプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険で

JWT送信→セッション(cookie 形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン 情報が奪われる危険が上がる

アプリ から直接ログイン 情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザー ID(あるいはそれに代わる特定可能な識別子)が含まれる

おそらく一般構成の仮定で書く

httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた

(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記の理由で納得できていない

アプリ から 情報が抜かれる危険性に関して

クライアントがネイティブアプリの場合、

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信→セッション(cookie 形式?)送信→セッションからuser_id取得　

で接続しても、おそらくcookie 形式で送れる何かもJWTらと同じ方法で抜かれると思われる

つまり cookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

つまり cookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初の段落の問題と同一と思っている

余談だが、ブコメの雰囲気に日和って「ユーザー IDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的 結論

expの期限と任意でセッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッション IDを含めれば安全」について

少なくともapi サーバ→ネイティブアプリに関して、セッション IDを含めても危険性は変わらない

正直web アプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたします

Permalink | 記事への反応(0) | 11:52

2018-09-09

■はてブはもうhttpとhttpsのエントリーを同じ扱いにしなよ

httpとhttpsで別のコンテンツが表示されるサイトなんて皆無だろ。

同じユーザのブクマは両方維持することもできそうだし、エントリーページにHSTSのフラグを持つようにすればいけんだろ。

anond:20180909092548

Permalink | 記事への反応(0) | 21:03

2018-09-03

■ブコメ 比較 はちま

http://www.tenohirakuru.info/?onlyComment=true&url=http%3A%2F%2Fnlab.itmedia.co.jp%2Fnl%2Farticles%2F1612%2F28%2Fnews088.html%2Chttp%3A%2F%2Fblog.esuteru.com%2Farchives%2F9182504.html

上：まとめサイト「はちま起稿」、DMM.comが運営していたことが判明 - ねとらぼ

下：「10歳の時、父が10万円を渡して言った。このお金は好きに使っていい。ただし毎月のお小遣いは君の持ち金の1％だ」はちま起稿

b:id:nisisinjuku

ゲスカプｗ

インベスターZみたいなお父さんだねｗ　まぁ、嘘松でもいいさ、意外と核心をついている部分もあると思うぜ。そうして僕はすぐにコンビニに向かった！

b:id:lbtmplz

またIT 企業=悪人の図式かー

倍プッシュだっ…！

b:id:white_rose

よくあんなサイト買収するな……。まあ似た者同士か

「おこずかい」が気になってしまって。中学生から毎月本やノート（？？）に投資してるのに

b:id:otihateten3510

どんどん出てくるw

うそまつううううううううわあああああああああああああああああああ

b:id:quality1

これは結構大きなニュースでは

このお父さんだからできただけでそこらの親がやってもうまく行かなさそう

b:id:sekreto

そんな一大事なの？

月利1パーセントなら、みんなからお金をかき集めるべき。

b:id:YukeSkywalker

DMMの糞カウンターが爆上げ中。

何やはちまか。開いて損した。

anond:20180903193133

Permalink | 記事への反応(2) | 20:17

2018-08-31

■anond:20180831001950

Webって仕事はいっぱいあるけどつまんないよ。やってることはユーザーの入力に応じてDBを操作して、DBの内容を画面に表示するという、よくある業務系と変わらんし。ただ、途中にHTTP挟んでるのとレンダリングが基本的にHTMLというのが特徴(というか足かせ)なだけ。プログラミングも面白い部分はほとんどフレームワークがカバーしてるから、残ってるのは細々としたすり合わせばかりだし。

Permalink | 記事への反応(1) | 08:12

2018-08-18

■俺にはAndroidアプリ開発なんて無理だわ…

Android Studioをダウンロードして公式のチュートリアルやってるんだけど、いきなりつまづいたし。

アプリ実行できないし。

https://developer.android.com/training/basics/firstapp/running-app

まで来たけどビルドが出来ないし。（ビルドじゃないのか、gradle sync？とかいうやつ？）

org.gradle.internal.resource.transport.http.HttpRequestException: Could not HEAD 'https://jcenter.bintray.com/org/ow2/asm/asm-analysis/5.1/asm-analysis-5.1-sources.jar'.

とか言われとるし。

ネット環境はちゃんとあるのに。

プロキシとかいらんことしてないのにし。

上のjarのドメインにping送ってみたら100%ロスしとるし。

オンラインのping 送信サービス使っても同じだし。

そのせいか、