「サーバ」を含む日記 RSS

はてなキーワード: サーバとは

2016-12-01

http://anond.hatelabo.jp/20161201075422

ハイクでも消したアカウントが残り続ける期間があって、中の人に聞いた話だったはずだが二つサーバがあって同期してるんだそうな。

なので一定期間すぎればハイク場合消えてた。バックアップ先が他のサーバ時間バックアップがかかってるならあるかも。

2016-11-20

新卒スキルなし社内SEさらに追記あり)

市の就職支援セミナーで紹介された機械製造会社

就職活動では文系学部ながらSE職を目指していたことが社長に伝わったらしく

「うちの会社営業システム更新してほしい」

との鶴の一声社内SEとして就職

最初既存営業システムを触るために1か月程度営業アシスタントとして働く

しかし肝心の社長プログラミングスキルはなく、研修にも連れて行ってもらえず

もちろん上司プログラミング経験者も社内にはいない(実質的上司社長に当たるが忙しく業務報告のみで終わる)

結局営業システムVBAで開発することが決定し、本で買った知識で外側(フォーム)を作成しOKサインを取る

しかし相変わらずコードが書けないため、自分が作ったフォームから要求される機能実装できない

就職先も自分で決めたものではない(親に他社の内定蹴りを強要された)し研修も行かせてもらえないし

ことごとく自分の気の弱さのせいで自分物事を決めたいように決められなくなっている

定時で帰れているくせに(仕事もひとりの部屋で窓際族のくせに)休日になったら寝たい以外のことをしたくなくなるくらい生命力が弱いのも災いしているんだろうなあ

追記

就職活動の経緯(親に内定蹴りを強要された)についてはhttp://anond.hatelabo.jp/20160119225411

に書いてあります

1月高速バス事故のあと親がヒスって路線バス運転職の内定を蹴らせたことは事実です

自分反論/主張できない気の弱さがいけないと常々思っています

さらに追記

最初C#で開発する予定でしたが、コードの書き方すらわからないのにサーバとの接続さらにわからないものをやらされるのは無理だったのでVBAで開発することになりました

社長曰く開発を外注することは「弊社の技術が身につかない」そうで嫌だそうです

大多数のプログラマは…

IT業界に努めてもうそろそろ二桁年。

そこそこの企業特にWeb系で渡り歩いた経験から真実を書こう。

一般的プログラマと呼ばれる人たちは

はっきり言う、ほとんどのプログラマ自称する人間の 9 割はコーダーである

言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。

そんな驚きの生体をここに晒していく。

一般的コーダー自称プログラマ)は、アプリケーションの基盤が作れない

標準化と呼ばれるプロセスで、プログラマ環境設計、組み合わせ、開発プラットフォームセットアップ、開発環境の構築手順作成、開発手順の作成必要技術考察を行う。

なぜそうなったのかは知らないが、一般的にそうなっている。

その環境に浸っているせいか、彼らはゼロベースものを作ることが出来ない。

彼らにできるのは HelloWorldコマンドプロンプトで表示するプログラム程度の事しか出来ない。

複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。

一般的コーダー自称プログラマ)は、保守性を考えない

彼らは自分に任されたものを動かせればタスクが終了する。

逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメント記載などの保守に関わることをしない。

それは彼らにとって「必要ない無駄作業」としか考えないのだ。

早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。

そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正地獄を見るという簡単論理に気づかない。

…何度味わっても気づかない。

一般的コーダー自称プログラマ)は、勉強しない。

一般的プログラマコーダー)は勉強をしない。

たとえするとしても、業務時間中に業務で使ってる技術ピンポイント学習するだけだ。

勉強会は確かに多い。「.dits」何かがいい例だ。

だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。

彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの?馬鹿か?」

あえて言おう、馬鹿は彼らだ。

一般的コーダー自称プログラマ)は、自分の使う道具がわからない

Web仕事をするならIDE統合開発環境エディタコンパイルテストデバッグ実行などを画面から行えるツール)はほとんど必須エディタで済ませる事も出来なくはない)が、彼らは状況に応じたセットアップができない。

たとえば「Mavenプロジェクト管理ツール)、checkstyleコーディング規約チェック)、editorconfig(改行、インデント文字コード設定)」が入っていたとする。

するとEclipseなどを使うとして

  1. どのプラグインを入れればいいか調べられない
  2. どうやってプロジェクトを取り込めばいいかからない
  3. プラグインを入れても設定方法がわからない(IDEデフォルト設定と、プロジェクト内の設定の違いを認識できない)
  4. IDE の設定画面がわからない

マニュアルチュートリアルを用意しないと、道具の使用もままならない。

一般的コーダー自称プログラマ)は、テストコードで書かない

テストをなるべく機械やらせようということの利点が理解できない。

コンパイルして動かして確かめればいいと本気で考えている。

そのために、何十回もコンパイルデプロイアクセスログインの手順を何度も繰り返す。

関連する他の修正を行うたびに繰り返す…。

そしてやっと動くとひと仕事終えたと満足感に浸る。

一般的コーダー自称プログラマ)は、プライドが無いか、変なプライドを持っている

ラリー・ウォールというとある有名な人物Perl開発者にしてC言語ハッカー)がいる。

彼の言う三大美徳に「傲慢」がある。

これは、自分の作るもの完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である

一般的コーダー自称プログラマ)は、このプライドはない。

彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。

同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。

変なプライドを持つコーダーは、それで運良く成功すると、自分知識は正しい、自分技術は十分なのだと考えている。

こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人環境のせいにする。

そして調べず周囲を苛立たせるのだ。

おわりに

土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない(んじゃないかと思う。)彼らは自分でなんでもやらないといけないからだ。

だが、大企業に飼われる子飼い企業派遣(そもそも人手のみを求められる企業)、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。

だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ

人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。

必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢思想はどうなんだと。

経営者マネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か?人員最適化だけを行って、生産性が伸び悩んでいないか

そのあたりは考えた方がいい。

エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase

http://futoase.hatenablog.com/entry/2016/11/19/155427



例示されている暴力はだいたい頭の悪い暴力なので反論できます


CGIには今の時代PHPを利用するのに、なぜ未だにPerlを使っているのか。処理速度も遅く、表現も難解だ。

では今あるシステム全部PHPリプレイスするとして、○人月工数必要ですがそのような予算はありません。



Go言語のもの表現力が低い。そんなものを利用するならJavaScalaで書くべきだ。ライブラリ豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。

ところでどうしてWindowsPCを開いてExcel文書作ってるのか教えてください。



Serverlessそのものサーバがなくなるわけではない。自身チューニングなど細かなリソース管理ができないPaaSを使って自身サービスの命運を預けるなんて馬鹿げている。

理屈の上ではオンプレミスIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。

みんな忙しいから結局何もやってないじゃないですか



iOSアプリのものプラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなもの技術をかけてどうするのか。

Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんものはチンケなものだ。そもそもUnityインフラエンジニアが覚えて意味があるのか。

流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか?

でも安心してください。すべてはUnity解決してくれます。そう、Unityならね。






とは言っても結局は私も暴力をふるう側の人間

例示された人たちに暴力ふるいたい。

windowsmacフロントエンドインフラ組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ!誰もお前がカバーしてない部分をサポートなんぞしねえからな!


ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ)

iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmaciphone買え(ios開発は何もかもmacxcode大前提

フロントエンドプログラマgo → goだけ使われても微妙。当然DBとの連携もあるんだよな?ん?(サーバサイドスクリプトDB連携のためにあるようなもの

サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから!(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも)

NintendoUnityインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityエディタ上で動くくらいを目標にすべきだ。

2016-11-18

メンバー設計書をwikiで書きましょうって提案された

私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。

UMLなどの作図にツール使用することはあっても、最終納品物としてはExcel画像として張り付けて提出していた。

もちろんExcel方眼紙については批判もあるのは理解しているが、開発者運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。

 

そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。

設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。

開発者運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwiki知識ほとんどない。

 

彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwiki用語集として活用していたそうだ。

wikiには顧客業務専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。

そういった運用をしているうちに彼はwiki自体設計書とできないか考え、調査したところ実際にwiki設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。

 

私も今調べてみたところwiki設計書を書くという運用をしている会社もあるようだが、メリットデメリットwiki知識があまりない私には判断しかねている。

ぱっと思いつくデメリットとしては、第一に、やはりマークアップ記述するコストが非常に大きいように思える。

記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコスト必要となるように思える。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

 

メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。

第二に、改訂履歴差分が標準で用意されていることもメリットであろう。

第三に、検索が容易であることがあげられる。この点はExcel比較して十分大きなメリットだと思っている。

 

私がぱっと思いつく限りではこんなもんである

はてな諸兄の中にwiki設計書を書いたことがある方がいれば、メリットデメリット、その他運用において気をつけるべきことなどあればご助言願いたい。

 

なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。

そのため自社の標準の設計テンプレート使用する予定だった。もちろんExcelである

 

また、設計作成使用するツールExcelWord以外の素晴らしいツールがあれば教えていただきたい。

どうかよろしくお頼み申し上げ候。

2016-11-14

エンジニア副業を始めるのに勇気が持てない話

新卒5年目エンジニアにはよくある話だが、何人かの大学の同期がフリーランスとしてガツガツ稼いでいるらしい。

それに触発されて、自分も何かエンジニア系の副業ができないかフリーランス求人サイトをみてみた。

なんか出来そうで出来なさそうな案件ばっかりだ。

いや、それなりに調べれば作れそうだが、はじめましての私にできるだろうか。

一応CもRubyRailsPHPSQLサーバサイド系もそれなりに業務趣味経験しているが、募集されている具体的な案件をみるととたんに不安になる。

そう不安なのだ

こういう自分スキルセットだけど、どうやってフリーランス案件を受け始めたか的なエントリがなかなか無い気がする。

平凡なエンジニアだけど、こういう状態から勇気を持って副業始めました的な。

情報に対しても受動的じゃだめなのかな、とりあえず挑戦してみるべきなのか。

2016-11-04

http://anond.hatelabo.jp/20161104160208

昔はマックバイナリのせいで解凍できないアーカイブ拡張子なし2バイト文字ファイル提出してきたりとか、リソースフォークファイルサーバゴミ大量生成みたいな実害があったんでMac信者大っ嫌いだったけど、最近アップル製品さなければ特に問題ないんでわりとどうでもいいなー。

2016-11-02

ガラケーがなくなる3つの理由

https://www.nttdocomo.co.jp/info/notice/page/161102_00_m.html

時代終焉・・・

根強いガラケー支持者はいるけど、いわゆるガラケー(≒Symbian3Gケータイ)はなくなる運命にある。

それは3つほどの(かなり通信側都合の)理由があると聞いた。

1 ガラケー向けパーツの枯渇

結構からではあるが、生産会社がほぼ無いためパーツ在庫がなくなると作れなくなる、と言われている。でも意外と長続きしているね。

2 スマホ高速化周波数

FOMA等の3G過去通信技術のため周波数利用効率が悪い。通信速度は通信大手3社にとっては最たる勝負どころであるので、LTE、その先の通信技術を考えると効率的通信技術にこそ周波数を割いておきたいところだろう。

3 技術伝承されていない

通信ウェブ会社の中でi-modeなどガラケー通信サーバアプリ開発技術ノウハウが途絶えて来ている。下手なところでは仕様すら残っておらず、現状動いているサービスでも、何が起こっているかからないので止まったらサービス終了、と割り切られているらしい。

2016-11-01

退職なさる先輩へ

近々退職なさる先輩へ、後輩からアドバイスです。



インデントや空白の有無にはきっちり規則性をもたせましょう

タブとスペース混じりのインデントなど、見るに堪えません。

きっちり規則を決めてコードを書きましょう。



Gitコミットメッセージをちゃんと書いてください

updateやfixなど英語単語だと何が変更されたのか非常にわかりにくいです。

あと職場英語圏の方はいなかったので無理に英語を使う必要はないと思います



手動でサーバを構築しないでください

環境再現することやサーバの中身を把握するのが困難になります

世の中にはAnsibleやItamaeなど便利なプロビジョニングツールがあるので是非使ってみてください。



手動でDBスキーマを変更しないでください

開発環境と本番環境で食い違いが生じてエラーが発生していましたよね。

DBマイグレーションツールを使うのをオススメします。



N+1問題などボトルネックになりやすい部分は気をつけましょう

キャッシュを設けても遅くなるものは遅くなるのです。

クエリの発行数や計算量など意識してみてください。



エラーが直ったかどうかはきちんと確認してください

動くかどうかも確認せずに「直ったよ」と嘘をつかれても他人迷惑しかなりません。

テストコードを書ければ良いのですが、最低限手動でもいいのでご自分確認してください。



コードドキュメント仕様は一致させてください

利用する側の人はドキュメントを見るので実際の挙動と異なっていると困惑します。

整合が起こらないように気をつけてください。



HTTPステータスコード意図にあったものを返しましょう

GETしただけなのに201を返すなど意図にあっていないものがありました。

ステータスコード意味を調べてよく考えてみてください。



他にも言いたいことは沢山ありますが、あまり長くなるのも迷惑かと思うのでこの辺でやめておきます

先輩は技術知識はたくさん持ち合わせていましたが、どうにも技術的に他人を思いやる文化を持ち合わせていなかったように思いました。

上記の点を直すことによって、そういった文化を養うことがエンジニアとしてのステップアップにつながるはずです。

次の職場でのますますのご活躍をお祈り申し上げます

業務系にWebアプリケーションが人気である理由がわからない

特に最近JavaScriptごりごり使ってるやつとか

一昔前なら軽量とか工数が少なく済むとか理由があったんだろうけど

今はJavaScriptごりごりでRichどころかFatになってるじゃん

マシンスペックも上がってるんだからもうクライアントサイドもサーバサイドもJavaでいいじゃん

 

JavaScriptただでさえ読みにくいのにライブラリが大量に使われててもうわけわからん

JavaScript使いたくないよ~( ノД`)シクシク…

2016-10-28

日本人残業が増えたのは電子化が原因

日本仕事効率が悪いって言われることについて思ってることを殴り書きしてみた

紙での処理をデジタルに置き換えただけの電子化

これはよく言われることだけど普通の国なら電子化によって効率化して仕事量は減る

ところが日本電子化によって仕事量が増えた

単に紙でやっていた作業電子化しただけなので

作業量はほぼ変わらずに習熟のコストけが上がった

Excel方眼紙PDFだらけのシステムはそのせい

本当なら電子化するときに紙では必要だったけど本質的必要じゃ無いものは削ったり

電子化することで自動化できる部分に関しては省略したりする必要があった

ただ特に大企業人間は「もしかしたら必要かもしれない」という恐怖心に勝つことができず

成功はないけれど失敗もない「ただ紙でやってた業務デジタル化した」だけに留めてしまった

中途半端電子化ルールの非明文化

さんざん議論して効率化するために導入したはずなのに大半の大企業は完全に電子化されてなくて

一部は印刷して手書きサイン必要だったり領収書原本を貼り付けないといけなかったり

別に法律で決まってないけど念のため紙で印刷して保存してたりする

日本人ハイコンテクストで会話するもんだからそういうルールは明文化されていなかったりして

新しい作業をするときに何をすればいいのかを調べるのことに凄く時間がかかる

Excel方眼紙PDFによる様式ファイル

紙でやってた処理をデジタル化しただけなので

本来デジタル的に入力させる項目もExcel入力させてそれを電子ファイルとして保存するというアホなことをやってる

Excel場合入力するときセルをはみ出ないか気にしたり入力値が間違ってないか別のファイルを参照にしながら確認したりして

紙に書くより時間がかかってるのでは?ということもある

PDF印刷して手書きで書いてスキャンして保存もよくある

様式ファイルを探すのも一苦労

管理していた頃は棚を探せば紙が出てきたけど

電子化によって共有ファイルサーバに格納を始めると

フォルダの奥底にある場合があってそうそ発見できないので逆に時間がかかる

部署毎にコピーを持ってたり過去データから様式を持って来たりすると

実は様式が変わってたりして二度手間になってまた余計な時間がかかる

社内技能の蓄積が難しい

「慣れてくれば早い」

という日本の古来からある謎の文化のせいで時間が経てば職人的になって効率も上がってくるんだけど

一方で人事異動システムは残ってるからその職人もいずれいなくなる

そして異動先では別のシステムファイルサーバが動いていたりしてレベルからやり直し

異動元では職人がいなくなったことで効率が下がり無駄な稼動が発生する

パワポ文化と長引く会議

これらに加えて海外企業特にIT系)やベンチャー系は電子化に強いので

プレゼン説明資料を大変綺麗・分かりやすく作ってくる

日本特に大企業の偉い人はそういうのが大変好きなので

「うちもあれぐらいのクオリティ資料作ってこんかい!」

という感じになってみんなひたすらパワポと睨めっこ

練りに練って情報量満載の資料を作って

プロジェクターで大写しにして会議するもんだから

そりゃみんな細かいところに突っ込んだり議論が二転三転したりして全然終わらない

偉い人の時間を潰すことは問題なので

偉い人の会議にかける前に事前チェックをする会議を開いてそこでチェックをする

その会議にかけるために(以下,2~3回のループ

セキュリティ対策とやめられないメール

標的型攻撃を初めとして近年のセキュリティ対策として

特に大企業暗号化リモートアクセス化が顕著

暗号化ネットワーク越しのせいで一つ一つの作業ストレスが溜まるし

リモートアクセスの端末がだいたいノートPCのせいで

画面が小さくて作業がしにくくまたストレスが溜まる

そのせいでしょーもないミスが起きると二度手間だし

再発防止の対策とか言い出して二重・三重のチェックをやりだす

メールがこれだけ危ないって言われてるのに他のメッセンジャーアプリは導入できず

結局メールを使ってコミュニケーションを取るんだけど

送信防止のための変なシステムが入ったり

ファイル暗号化してパスワード別に送るという謎セキュリティのせいで

いちいちコミュニケーション取るだけでやたら時間がかかる


コンプライアンス重視

そんな雑務を高い給料払ってる正社員にさせるのはもったいないので

派遣を雇って作業させたり手伝わせたりしてたら

コンプライアンスとか請負法とか言い出してそっちの管理をするために余計な稼動が発生

残業が増えてくると組合が五月蠅く言ってきたり

どっかのバカ違法なことを平気でやったりするから

再発防止の水平展開とか言い出して二重・三重のチェックをやりだす

電子化をやり直す!

だいたい大企業中の人はこのことに気付いてて

電子化をやり直すために新しいシステムを入れようとするんだけど

前述の通り日本人ハイコンテクストで会話するから本当に必要業務っていうのを抽出しにくくて

だいたい新しいシステムは何かが足りなかったりする

結局二重運用されたり運用対処(紙ベース)とかされたりして

効率全然変わらないのがオチ

だったらDevOps

最近言い出したのが

「社内システムはDevOps!」

って奴で要は内製とかもして自分たちで良くしていこうっていう動き

はいプログラム書けるやつは大企業に見切りをつけて外資ベンチャーに移ってるし

まともに書ける人間が残ってるとは思えないからこれも上手く行かないと思う

やるなら新入社員に美味い餌をぶら下げてプログラム書ける奴をバンバン採用するとこからじゃないか

来てくれるかどうか分かんないけど

在宅勤務しながら転職ドラフトに参加したけど指名が貰えなかった。

歴1x年のサーバサイド、年収4xx万で参加してみたんだけど、在宅勤務希望というところがダメだった模様。いちおう5〜6社は検討中になったんだけど、おおかた上記のところを見落としていたものと思う。

転職ドラフト企業レジュメを見られた時と、メモを取られた時(内容は判らない)に足跡が残るんだけど、きっと「在宅✕」みたいな内容を残していたに違いない。まあ在宅勤務とか言うレアな条件を書く人間の方が迷惑存在であろう事は想像に難くないが。

それなりにスキルセットには自信があったし、同じスキルセットの人と比べてもかなり安めの年収を設定したつもりなんだけど、それでもやっぱり世の中の大多数の企業普通に出社できる人間じゃないとダメ、と考えているという事に尽きるのだろう。在宅勤務の機運が高まっている昨今とは言え、いくら綺麗なコードを書けても、OSSコミットしてても、幅広い分野での経験があっても、出社できない人は要りませんということで、それはもっともな話だと思う。いちおう月に何回かだったら出社できますよ、とは書いたんだけど。インターネットが発達しても依然として場所に縛られなくてはいけない時代はまだまだ続きそうだ。

まあそういった意味では少なからず得るものがあったイベントだったし、参加してよかったなと思う。

こういう話をするとおおかた「フリーランスでやればいいじゃん」と言われて終わりなんだけど、それでも一応参加してみたかったという所を汲んでもらえれば幸いです。

2016-10-25

サバ缶とサバ

サバ缶:サーバを缶詰にしたもの。スケーラブルで耐久性に優れる。DCでは数千個のサバ缶が常温で稼働。

サバ管:鯖の管理者。漁獲ログを読む、アニサキス感染の検疫アラートが出たら24時間365日現場に飛ばなくてはいけない。ヘマをすると上からも下からも吊し上げられる。これを〆サバという。

2016-10-23

誰か頼む

手に余るから誰か拡散してくれ。

gmail.comに対してgmai.comやgmail.coを取って、フィッシングをしたり、

黙って誤送信メールを受け取るだけの手法がある。

特に送信メール待ち受け、はなかなか気づけないので怖い。

で、タイポやcoドメインは既知だと思うんだけど、co.jpに対して

hoge.co.jpに対してhogeco.jpを取る方法はあまり使われてない。(neでもgoでも同じ)

海外大手は軒並み取られてる.coも、日本系だと結構空いてる。

でも既に取られている類似ドメインもあり、誤送信したメールはそこに吸い込まれてる。

実際に奇跡的にまだ空いてたexciteco.jpには大量に誤送信が来てて、結構送信はある模様。

フリーメールでも企業でも当然同じ。

例えばxxx@hatenane.jpメールを送るとvalue-domainのメールサーバに届く模様。これはてなじゃないよね?


で、これに気付いて、co.jpドメインの持ち主全員に連絡するのも無理だなあ、ということでJPRSに連絡してみた。

が、電話番号教えないと注意喚起はできないと拒否され、黙っていても気付かれずに被害が増えるだけなので、

ここで公開することにした。

後は情強の集まる増田に託す。


ついでに言うとセカンレベルが取れるccTLDみんな同じなので、教えておいて下さい。

hogeco.jpはがら空きだったけど、他の国ではもうやられてるかもね。

やばい1!ままに怒られる!!!

動画リスト 新着動画

未成年の方の年齢詐称によるご登録誤作動によるご登録につきましては、メール電話にてご連絡の上退会申請キャンセルを行ってください。

キャンセル・退会申請・お問い合わせの際、お客様ID必要となりますお客様IDは下記のものをご利用ください。

お客様ID 3442628919

電話でのお問合せはこちらより03-4540-437510:00 ~ 20:00

125,000円(税別)

3442628919

2016年10月23日 19時30分

2016年10月24日 19時30分

2016年10月26日

本日の特選動画再生

再生日時:2016年10月23日 19時30分

注意事項当サイト青少年保護育成条例やその他法律法令により二十歳未満の方のご利用は固く禁止しております。二十歳未満の方は速やかにご退場下さい。動画のご視聴には当サイトが定める利用規約同意登録必要になります。次へから進みますと当該内容の確認及び承諾をしたものとみなされます。当サイトは三百六十五日間税別二十五万円のアダルト配信サービスです。ご登録ご利用後はご利用料金が発生いたします。また、会社業務用の機器・端末からのご利用も固く禁じます利用規約の内容をよくご確認の上、ご利用ください。重要事項本重要事項は利用規約を要約しております。本サービスをご利用される場合は必ず利用規約確認し承諾の上同意された方のみご利用下さい。利用確認画面で年齢選択及び利用規約同意をし最終確認画面で利用内容をご確認、承諾し進んだ時点で登録完了の通知画面が表示されご登録完了し年間税別二十五万円の利用料金が発生します。料金の支払期日はご登録から三日以内となり、翌日まではキャンペーン期間対象となります。ご利用期間後は自動退会となります

注本サイト名:videoparty(以下、本サイトという。)会員利用規約(以下、本規約という。)は、videoparty動画運営事務局(以下、当社という。)が提供する会員向け動画配信サービス(以下、本サービスという。)をご利用される全ての会員様(以下、会員といいます)に適用されます

第一条 提供サービス

サイト提供する本サービスは、アダルトに類される性的画像映像の利用を希望する二十歳以上の成人だけを対象制作されたものである青少年保護育成条例やその他法律法令により二十歳未満の方の利用を禁止する。また、成人であっても本サービスの内容を好まない方の利用を禁止する。本サービスアダルトに類される画像映像の表示、配信を行っているため、勤務先や第三者の所有しているパソコンからの利用を禁止する。禁止されている項目に該当する状態で本サイトを利用し、勤務先や第三者問題が発生した場合でも、当社はその一切の責任を負わない。

二条 会員登録

サイト内で定める利用確認(本サービス利用申し込み)画面にて、年齢が二十歳以上で最上段の料金表記、本規約、注意事項、重要事項を全て読み承諾した後、最終確認画面(利用方法登録内容の確認)で年齢、料金表記、本規約、注意事項、重要事項を再度確認、承諾した上で、登録完了の通知画面が表示された時点で利用契約が締結し、本サイトの会員と定められ会員登録完了する。尚、会員登録無料である。会員の都合による一方的キャンセルは受けられないものとする。本サービスクーリングオフ適応対象外である

第三条 利用期間

  本サービスを利用できる期間は、お客様IDが発行され登録した日から三百六十五日間と定める。利用期間後は自動的に退会処理が行われ、本サービス提供が終了する。但し、支払期限を過ぎても料金が未納の場合は退会処理は行われず、また利用可能サービス制限される。

四条 自己責任原理

会員はお客様IDにより本サービスを利用してなされた一切の行為およびその結果について、当該行為自己がしたか否かを問わず、その責任を負うものとする。 当社は当該行為およびその結果により会員が損害、被害を被った場合といえども、何らの責任を負わない。また、本サービス内各コンテンツを利用するにあたり会員に生じたいかなる損害に関しても、一切その賠償責任を負わない。本サービスの利用により当社または第三者に対して損害を与えた場合(会員が、この規約上の義務を履行しないことにより第三者または当社が損害を被った場合も含む。)自己責任費用をもって損害を賠償するものとする。会員が二十歳以上であっても、会員の使用する端末機器を二十歳未満の非会員が使用し、本サイトアクセスおよび本サービスの利用、閲覧があった場合、当社は一切の責任を負わず、会員の自己責任をもってこれを解決する。

五条 サービスの利用料

利用料金の支払いは後払い方式となり、会員登録から三日以内を支払いの期限とする。本サービスの利用料金は、定額税別二十五万円とし、キャンペーン間中は税別十二万五千円で利用ができるものとする。ただし支払いに係る必要手数料等は、全て会員の負担とする。支払われた利用料金は、過払い以外の返金は認められないものとする。特別事由が認められない以上、料金は固定額であり、日割り、分割払い、割引等は認めらず代物弁済での支払いも可能ものとする。支払期限を超過しても料金の確認が取れなかった場合は、弁護士協議の上然るべき対応を取る場合がある。

六条 個人情報の取扱い

サイトサービス性質登録時に不必要個人情報名前電話番号、住所、メールアドレス等)は取得しないものとする。また、問合せ時や利用確認時に取得した個人情報の取り扱いに関しては、第三者に無断で開示、転送転売することを一切行わないものとする。但し、法律による要請裁判所から照会が求められた場合には、会員の同意なく開示する場合がある。

七条 利用規約変更の権利

サイトは会員に事前に予告する事なく、コンテンツ及び利用規約の内容全てを、いかなる時でも変更する権利を有する。変更後の内容については、本サイトに表示された時より効力が生じるものとする。

八条 コンピュータシステム要件

サイトおよび本サービスを利用する際は、自己費用責任で、任意電気通信サービスを経由して接続する本サービスサービスを個々のユーザーに応じた設定にするため、クッキーなどの技術使用して会員との通信の内容を記録するものとする。本サービスは、ブラウザクッキー機能有効状態で正しく動作するものであり、万が一ブラウザクッキー機能無効にした事が原因で本サービスを受けられない自体が生じても、運営者は一切の責任を負わないものとする。

第九条 著作権商標等の利用制限

サービスに含まれデータ情報文章ソフトウェア等一切の著作物に関する著作権は当社またはコンテンツ提供者他第三者帰属するものであり、会員は、これらを著作権法で認められた私的利用の範囲をこえる複製及び利用することはできない。また、本サービスに含まれる一切の商標等は当社またはコンテンツ提供者他第三者登録商標または商標であり、会員はこれらを無断で使用することはできない。会員は、前二項に違反する行為第三者にさせることはできない。

第十条 禁止事項

会員は、本サービスを利用するにあたり、以下の行為を行わないものとする。本サービス第三者に無断で使用させる事。法令条例公序良俗および本規約違反する行為。本サイトもしくは他の著作権商標権等の知的財産権侵害する行為、または侵害するおそれのある行為。本サービスサーバおよびネットワーク機器等に対して不正アクセスを行う行為、又はこれらを試みる行為有害プログラム及びデータ等を本サービスを通じて、又は本サービスに関連して使用し、もしくは提供する行為。本サービス又は第三者財産プライバシー著作権等の知的財産権及びその他一切の権利侵害する行為第三者なりすましての本サービスの利用、及び第三者不利益を与える一切の行為。本サービスを通じての宗教政治に関わる行為。上記各号の他、条例、本サービス運営妨害、又は不利益を与える行為、その他当社が不適切判断する行為

第十一条 会員登録の解除

当社は、会員が禁止事項各号の禁止行為を行った場合、当該会員に対するサービスを停止し、会員登録強制的に解除することができる。

第十二条 免責事項

サービス動画再生に適合していないブラウザを利用し、再生ができない場合、当社は会員に対し何ら責任を負わないものとする。当社は本サービスに関していかなる保証もせず、当社は本サービスの可用性、信頼性、正確性及び利用目的との適合性に対する保証から一切免責される。本サービスは、当社が必要と認められる場合、会員に事前に通知することなく本サービスの全部又は一部の運営を中断、中止することができるものとし、これらの場合でも、当社は会員に対し何らの責任を負わないものとする。

十三条 準拠

規約に関する準拠法は、日本国法とする。本規約に関する紛争については、東京地方裁判所第一審の専属合意管轄裁判所とする。

利用確認ページ上部の『利用規約及び注意事項重要事項を確認し承諾の上年間税別二十五万円のサービス登録する方ははいを押してお進みください。』を確認

年齢選択フォーム20歳以上 利用規約同意します。』で20歳以上である事の確認利用規約同意

料金表示『抜き放題見放題!!年間税別二十五万円利用登録はこの次すぐ!!』 を確認

注意事項及び重要事項、利用規約の各条項確認

チェックボックス利用規約同意して進む』のチェックを確認し進む

最終確認ページ上部の『利用規約及び注意事項重要事項を確認し承諾の上年間税別二十五万円のサービス登録する方ははいを押してお進みください。』を確認

登録の流れを確認登録

キャンセル

ログイン

サポート

ご入金方法

退会手続き

3442628919

03-4540-4375

10:00 ~ 20:00

ニコ動で感じる技術進化

ニコ動技術の発展を実感する。

いい加減flashで低画質なのは00年代から化石のようになっているし、サーバがクソ重なのも不快なので見ていなかった。久しぶりに見たら全然変わってないでやんの。

だけど、昔は初音ミク的な奴の音声は字幕がないとなにを言っているか全然からなかったが、最近結構分かるようになってきたので正直びっくりしてる。

2016-10-19

将棋不正を立証するには?

リモート将棋ソフトを使ってた場合、当日のIPアドレスなどからサーバ管理会社に問い合わせて調べる

ローカル将棋ソフトを使っていた場合、端末内のアプリOSログを徹底的に洗う。端末がワイプされていた場合可能な限り復元して検証する


ここまでやって判明しなければ無実と認めても良いと思う。

これ以上追求しようがないので。(コスト度外視)


現状、不正派も不正否定派も、棋力に合わない打ち方とかどーとかフワッとしたことしか言ってないので。

将棋の分からない1人の外野としてはこのくらいしないと白黒つかないと思うんだけどどうなの?

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-10-14

http://anond.hatelabo.jp/20161013112456

アプリフロントインフラサーバサイドもできる俺最強過ぎる

しか仕事ではどんなに出来ても一千万辺りに壁がある模様

季節の変わり目に風邪ひき増田簀巻き日背蟹目利若の津席(回文

うーん、

この時期、

昼間はちょっと暑かった

朝晩は寒いから

気温の差が激しくて、

ちょっと身体冷やしちゃう風邪引いちゃうのよね。

もう、みんなも気をつけてね!

なるべく身体を冷やさないようにしましょ。

結構、寝るとき腹巻きすると

お腹が温かくて快適よ!

まあ、季節の変わり目、体調もだけど

機械調子が悪くなっちゃうのかしら?

友達んちのウォーラーサーバがお湯が出なくなっちゃったって、

聞いたらコンセントが抜けてたんだって

そりゃお湯出るわけないわよね。

まあ、季節の変わり目だから仕方ないわね。

うふふ。

みんなも風邪だけには気をつけてね。




今日朝ご飯

ホット玉子焼きサンドにしてみました。

ふっくら柔らかい玉子焼きが風味豊に口の中に広がるわ。

そして、トマトの酸味と絶妙なマイッチングって言うほどのマッチング

朝のサンドイッチって幸せよね!

デトックスウォーター

うそう、

思い出したわ!

寒くなってきたと言えば

ホッツ白湯

これに限るわよ!

白湯だけで物足りなかったら、

昆布梅干しフレーバーを加えて楽しむことが出来るわよ!

鰹節なんかもオススメね!

色々試してみてちょんまげ




すいすいすいようび~

今日も頑張りましょう!

2016-10-13

木村岳史ボケ老人

いつもお世話になっておりますITベンダーです。突然で恐縮ですが、このボケ老人は何を言っているんですか。

https://twitter.com/toukatsujin/status/786338202705506305


昨日の東京停電で、UPS無停電電源装置)がありながらサーバーがダウンしたITベンダーがある。なんでも、データセンター認証を取る目的のためだけに、安物のUPSを導入。

安物すぎて容量が足りず、1~2分しか給電できない。で、サーバーシャットダウンが間に合わなかったそうだ。


UPSの蓄電量:機器の消費電源容量によるんですが、都内のきちんとしたDC事業者アット東京メーカー系列IDCフロンティアを指しています)でも、

UPSで堪えうる時間は数分程度です。この場合UPSの蓄電容量が間違っていたとは言い切れません。

そもそもUPS用途は下記2種類に分かれます

ツイートでも書かれている通りシャットダウンまでの時間稼ぎです。

その間PowerChute(まだ現役なの?)等の電源管理ソフト安全シャットダウンを実行します。

①の間にサーバシャットダウンプロセス完了しないことはありえます

今回はそれでしょう。それを挙げて「サーバダウンしたITベンダーがいる」はおかしいだろ。正常にサーバダウンしてるんだよ。

停電したら止まる前提でインフラを構築していただけの話。


UPSで持ち堪えている間、非常用発言機への切り替えを行います

通常非常用発電機の起動・電源切り替えのトライには数分程度かかるため、その間をUPSが持ち堪えます

あと何?データセンター認証ってどれのこと?ISO27001?LEED?FISC?そもそも非発もないのにそんな認証取らなくないですか?

サーバダウンは悪」という宗教はやめませんか?サーバは止まります。止まって再起動します。

止めてもいいシステムだったから電源冗長もないところに放り込んであったんでしょ。ならそれでいいんじゃないですか?


恐らくボケ老人はUPS用途も知らずに①と②を混同したんだと思います。かわいそう。引退しろ。何も知らないくせに伝聞で物を書くな。

そもそもサーバダウンしたベンダーってどこなんだよ。ジャーナリストだろ?ジャーナリスト様なんだろ?バイネームで書いてくれよ。なんで書かないんだよ。

他のツイートにしても「聞いたところによると」「うわさでは」なんて記述が目立つが、

どこの誰がおもしろ毒舌芸人のお前にそんな噂を流すんだよ。誰なんだ教えてくれ。

ちなみに①はITインフラ業界では「なんちゃってデータセンター」と呼ばれており、要はおっきめのサーバルームなんだが、

実際問題都内首都圏に今だ多数存在するので、このタイミングで潰れていただければ幸いです。

そもそもこのオッサン。彼は日経ITなんかで連載するWebライターです。

スタンスは「多重下請け構造」「無能情シス」「日系SIer」「レガシー」の批判

そんですきなのが「アジャイル」「内製」「ビッグデータ」「IoT」。

あのな、お前の好きな外資の某巨大クラウドビッグデータ分析基盤だって綺麗なウォーターホール設計書で書かれてるわ。

設計書さえなくなれば手戻りとバグがなくなるなんて幻想もいいところ。偉そうなやつに反対すれば国がよくなると思ってEUから抜けちゃった天然かお前は。

こういった逆張り無責任に目立つことさえ言っておけば、

批判が集まりバカが信じ込みページビュー信者を同時に手に入れられるバカげた仕組みは、

人類脳みそを悪くする原因になるのでよろしくないと思います

この人のコラムタイトルが「木村岳史の極限暴論!」なので、

恐らく裏を取る気もなければ、自分記事論理的整合性を与えないことに対しても自覚的なのだと予想されます

腹に据えかねて何度かリプライ反論したこともありますが、すべて無視して自分意見同調する声のみリツイートを続けていたので、

これから自分の頭の中に囁きかけてくる「噂」にだけ耳を傾けてクソ記事の量産を止めないことと存じます

考えを改めよ、と言っても聞かないと思うのでせめて皆様におかれましては毒蝮三太夫彦麻呂と同じディレクトリに格納頂けます様お願い申し上げます

会社をクビになってSEを辞めようと思っている

プログラマSEになって8年。

プログラマの時はLinuxカーネル書き換えたり、Windowsオリジナルインストーラ作ったり、Pro*Cやったり、まぁとにかく時流に乗って色々やった。

SEになって、いきなり最上工程やらされた。どんな人間でも1年はマニュアルと睨めっこするような複雑なサーバ運用ルールを決める仕事会社同士のぶつかり合いを見た。地方出張する楽しみを知った。某オープンソースサーバアプリを調べろと言われ、オープンソースな上にプログラマ経験者だからバグ解消までさせられた。一人で殆どの面倒を見たそのサービス島耕作宣伝してくれるまでになった。

去年、パワハラ適応障害になった。「使えねぇヤツと判断したらオレはすぐぶっ潰すんだ」と常日頃から言い切る定年間際の大手IT企業出世せず現場に居座るオッサン、と言えば大体想像出来るだろうか。そんなのと対面させられ、間違った知識を正したら逆に「使えないヤツ」扱いされ、酷い扱いを受けた。

2ヶ月会社を休んだ。

それから社会復帰して、銀行システム仕事をした。常に10個ぐらいの仕事が振ってくるような場所で、頑張った。SEじゃない会計仕事なども回ってきた。今までに無い知識を次から次に求められた。仕事中にインターネットが出来ないので、電車の行き帰りでスマホ勉強しながら仕事した。

どんどん仕事が増えて、朝7:30から夜21:30までが常態化して、身体を壊した。

気持ちばかりの慰労金を貰って、2日前、会社をクビになった。

----

クビになったその足で、前のプログラマだった頃にいた会社に行った。社長アルツハイマーになって3年目、よろよろになりながらも、社長業を続けていた。中小IT企業地獄だと思った。例え社長になったとしても、そこまで働かないと会社は成り立たないほどになっていた。

派遣法改正からもう、IT派遣は美味しくないよ、早くスピンアウトした方がいい」

社長は首を叩きながら言った。アルツハイマーの症状が首に出て、首が辛くて辛くてたまらない、との事だった。

「オレなら農業オススメするよ。地方の、援助金が出るような所に行ってさ、楽に作れるような野菜だけ作って、それで暮らしていける」

まり真に受けずにおこう、と思った。自分の将来は自分で決めるしかない。

----

今月はもう働かないと心に決めた。

労働で壊した身体を治さないと。精神の疲労、肉体の疲労、神経の疲労。それぞれ別で、それぞれ抜かないと大変な事になる。それは前回の適応障害の時に学んだ。

プログラマときにも適応障害になったから、生涯3度目の適応障害。慎重に行動したい。

次は何をするのか、今の時点で全く決めていない。

知り合い連中には「文章を書く仕事をしなよ」と言われた。「自分文章作法等、文章を書く仕事に求められる基本知識が全くない」と言ったところ「文章に力があるから、そんなの要らないんじゃないか」と言われた。自分の事ではない他人事なのだから適当で当たり前、仕方ないなと思った。

漫画を描いてコミケでまだ現役サークルで頑張っているが、創作で食っていくのは難しい事を知っている。

----

さて、次は何をしようか。

漠然と考える。

こんな文章を書くぐらいの暇はある。色々な事に挑戦してみたい。

サークルもっと頑張って売上を伸ばしたところで、多分、生活できるほどには成長しないだろうし、同人ジャンルに引っ張られる上に売れ筋ジャンルは読めないし、そもそも好きでもないジャンル同人をやりたくないしで、同人生活する、というのは無理だろう。

今時個人で開発したスマホアプリ収入を望むのも難しいだろう。

農業は奥さんに止められた。

今までの自分には無い、新しい事に挑戦した方がいいのかも知れないな、とか色々思っているが、何しろ会社をクビになって二日目。状況がまだ自分の頭の中でまとまりきっていない。既に辞めたのに、職場のアレコレが気になってしまったりする。既に辞めたのだから関係ないはずなのに。

まだ、今の自分には休養が必要なんだと思う。

家族理解さえあれば、少しの間、休みたい。その家族理解がどこまで期待できるかなんだけど、まぁ3度目なんだから、いい加減、判ってくれているとは思うんだけど、うーん、判っていないかも知れない。

2016-10-12

転職先がクソだった話(おもにメンツ

いまは別の会社に勤めているが、以前の会社があまりにも残念だった。

ちょっと気持ちが落ち着いてきたのと、落ち着いてきたものの誰かに知っておいてもらいたいので記すこととする。

企業口コミサイトって手もあったが、なんとなくアレなんで。




例によって特定を恐れ、ある程度はぼかすものとする(が、事実である




昨年の夏頃から転職活動を始め、自分なりに納得した上で初冬に転職した、理由Uターンである

小生は都内システム開発の職に就いていたが、転職先も地方システム開発である




Uターンということもあり、年収仕事内容が下がることは覚悟の上だった。

仕事の内容が下がるとは、やはり都内でイケイケな技術を使って、イケイケなサービスを作っていた側からすると、劣るということである

断りを入れると、すべてが転職活動の失敗に紐づくし、それは自分責任の以上で以下ではない。

が、考えていた以上の煮え湯を飲まされることとなる




一例を出すとする。




まず前提

そこでは、とあるシステムパッケージ開発とその納品作業カスタマイズ含む)を行っていた。

納品先はオンプレで、それに伴う機材の調達自分たちで行う。

納品作業には顧客との動作確認や他システムとの連携テストが含まれる。




うすうすおかしいなっと思うことがあったが、連携テストの際に辞めることを決意する決定打があった。

さぶばーじょんつかったことあるの?」

コレである

なんかよく分からない叱責の中で、この言葉がでてきたのである

耳を疑った。

多分人生で初めて、耳を疑った。

いままで信頼してきた自分の耳を疑った。




そもそもこの会社では到底SVNとは思えないSVNの使い方をしていた。

まぁよくいっても単なるファイルサーバとしての使い方である

差分管理なんてあったものではない。

なんせソースコードの改修箇所は、Excel管理されているのだから

ちなみに想像つくと思うが、ソースコードに改修番号みたいなコメントがあって、その改修番号でExcelと紐付いているという。

そんなこんなでソースコードにはどこぞの納品先でカスタマイズされた分岐やらループやらが散在して、なんのことかよくわからなくなっている。




まぁやり方はそれぞれだから百歩譲って許そう。

しかし許せないのは、あたかもそれが正解かのように叱責され、でてきたあの言葉である

これを言ってきた連中は新卒で入ってずっといるor長いこと会社にいるっといったメンツである

毒されている、というか技術者としての向上心もない、もはや彼らはこの会社しか生きられないだろう。




自分がもし逆の立場なら

「ごめんね、ここでのSVNの使い方はこうなんだ、いま改善しようとしているところだから、とりあえずは我慢してね」

とか言いようがあるだろう。

それもなく、運用ルール説明もせずに間違っていたら怒るという。

(彼らは説明したと言っているが、間違いなくいっていない。こんなルールを聞かせれて覚えていない訳がない、彼らのなかで常識となっているから言ったと思いこんでいるのだろう。)




ボカしているのでうまく伝わらないと思うが、これがことの顛末である

もちろん他にも首を傾げるところはある、けしてコレだけではない。




書いてて思ってが本当に内容をボカす必要があったのだろうか。

なぜなら彼らは、はてブも知らなければ当然ながら増田も知らないだろう。

故にこの増田はてブトップにきたとしても、みることはないだろう。

それくらいアンテナが低いのである




もうちょっとだけ、なんだかなーっと思ったことを言わせてほしい。

例によって彼らもソシャゲをする一端のサラリーマンなわけだが、Ingressを知らないことには驚いた。

ここまで地方技術者レベルが低いのかと思った。

(後にいまの会社転職し、この会社だけの話だとわかった。)

別にIngressを知らないかレベルが低いと言ってるわけではないが、それぐらい知っておこうよっていうことが多々ある。




冒頭でも言ったが、これはすべて自分責任である

責任であるからこそ許せない。

どうやったら防げたのだろうか。

しろ自分がその会社かえるべきだったんじゃなかろうか。

(それはない、人のやる気さえを奪う負であったから、ここにいたらマイナスしかない)

やっといろいろ考えられるようになってきたので、今回まとめてみることにした。




不快に思う人がいたら申し訳ないです。

賛同してくれる人がいたら嬉しいです。




最後

今回の登場人物はいないが、その地方営業所の一番エラいとされる(役職名を出したくない)人がいる。

そいつもっと何もわかっていないバカである