「ステータスコード」を含む日記 RSS

はてなキーワード: ステータスコードとは

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

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

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2016-11-01

退職なさる先輩へ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2015-11-26

やる気のステータスコード

200 やる気 OK
やる気マンマである
201 やる気 Created
これから本気出す
202 やる気 Accepted
やる気があることだけは分かった
204 やる気 No Content
見せかけだけのやる気である
400 やる気 Malformed
そんなところにやる気を見せられても…
401 やる気 Unauthorized
やる気あるのは分かったけど、誰だお前?
403 やる気 Forbidden
お前はやる気になるな!
404 やる気 Not Found
今はやる気無くなっちゃった
405 やる気 Method Not Allowed
お前はやる気出すキャラじゃないだろう
409 やる気 Conflict
さっき、別のことの方がやる気あるって言うてたやん
410 やる気 Gone
さないでください…
413 やる気 Too Large
恐ろしいやる気だ…付き合いきれん
500 やる気 Internal Server Error
やる気…やる気…やr
501 やる気 Not implemented
フッ…オレは生まれながらにして、やる気を出せない人間なのさっ…
503 やる気 Not available
やる気とか出してどうこうなる場合ちゃうっつーの

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2013-12-18

告白で例えるHTTP 2.0

何故か昔からHTTP告白を例えに説明されてきました

そんなHTTPも新しいHTTP2.0検討されています

そこで、HTTP2.0ではどんな告白が可能になったのか告白で例えていきましょう。

HTTP2.0は随分とフォーマットが変わりましたが、告白方法電話だったものメールになりLINEになりと媒体が変わったものの伝えたい事は変わっておりません(セマンティクスは維持されています)。

なので、みなさんが大好きなステータスコードHTTP1.xの頃と殆ど変わっていません。HTTPヘッダも同様です。

ですが、新機能は多くあります

物凄く簡単に、かつ誤解を恐れず紹介したいと思います

メッセージの多重化(Multiplexing)

HTTP1.xでは、告白したら返事を貰わないと次の告白は出来ませんでした。

HTTP2.0では、相手の返答を待たずに続けて(同じ相手に)告白をすることが出来るようになりました。

ただあまりしつこいと、あっち行けと言われてしまうかもしれません(GOAWAYフレーム)

優先付け(prioritization)

同時に複数回告白できるようになったため、どの告白文についてより早く返事をして欲しいか優先度を指定できるようになりました。

ただし優先度付けしたところで、相手がそれを汲み取ってくれるとは限らないようです

要求を待たずに返事をする(server push)

今までは、女の子側は告白を受けてやっと返答が出来ました。

「好きです」→「ごめんなさい」

という感じです。

HTTP1.xで、以下の様なパターンがあったとしま

男「好きです」→ 女「ごめんなさい」→男 「では友達からということで...」→女 「それもいやです」

HTTP2.0では女の子は、男の次の要求が想定できる場合、要求が来る前に返事を返すことも出来るようになりました。

男「好きです」→ 女「ごめんなさい」「友達になるのも無理です!!」

見出し情報の圧縮(HPACK)

HTTP2.0では例えば複数回告白する場合は、二回目以降は

「~~さんへ」(host)や「2013/12/18」(date)といったもの自分名前(User-Agent)といったものはわざわざ書かなくても良くなりました。

また、辞書を使って効率よく文章を伝えることも出来ます

告白方法合意(upgrade mechanism)

現状HTTP1.xと言う旧式の告白方法と、HTTP2.0という新しい告白方法存在することになります

男は最初にどちらの方法告白するか、女の子合意を得る必要が出てきました。

2008-12-30

ステータスコード大戦

「出でよ…コード403、フォビドゥン……!」 ズガァァァァン!!

「くっ…!この世の全てを禁止し破滅に追いやった伝説の403/フォビドゥンが、ついに目覚めてしまった…!!!」

「頼む!世界を救ってくれ!コード200!オーケー!!!」 ドォォォォン!!

「ククク、200ごときが403を倒せると思うか……?まるでスッポンが月に勝負を仕掛けるようなものじゃないか……!」

「こんな危ないトコにゃあいられねえや、オラは逃げて高みの見物じゃあ!コード302、ファウンド来い!」

2007-09-17

ameblo問題について別の視点から一言いっておく

http://anond.hatelabo.jp/20070914184742

http://mala.nowa.jp/entry/fa12686ffd

http://mala.nowa.jp/entry/d0bef11623

初めに勘違いされてもアレなんで言っときますが、ameblo中の人ではないのであしからず。あとキレキャラという芸風なんでご愛嬌な。先にいっとかねーと人格攻撃されそうだからな。

お前らamebloキモイだとかクズだとか言いたい放題言ってるがそもそもamebloのどこが悪かったってんだよ。

ステータスコード間違えてるとか言ってるけど、正常なRSSデータを正常なステータスコードで返してるんだからこれだけみれば間違っちゃいねーよ。

配信停止してるのならRSSデータ返すなといいたいのはわかるが、そもそもお前ら認識間違ってるよ。

RSSとしては(内容はともかく)いたって正常なんだから文句言われる筋合いはねーよ。例えばGIGAZINEだってフィードにウザい広告混ぜてくるだろ?

RSSとしてフォーマットが正しければ基本、何でもありなんだよ。あとはモラルだとかマナーの問題だろ?

amebloが「只今RSS取得が行えません」ってフィード返してくるんならその時間にクローラー行かないようにするとか、これこれこういう場合はデータを反映しないとか対策練れよ。

なんだか上から目線で文句ばっか言ってるけど、お前らamebloRSSデータを取得しに行ってやってるみたいな感覚になってんじゃねぇか?

逆だよ逆。

amebloが有益な情報をお前らに提供してやってんだよ。お前らは無料でその恩恵にあずかってるだけなんだよ。

もしamebloがずっとこのスタンスでやっていくつもりだったらRSSリーダー開発元はどーする気だったんだ?

ぼーっと指くわえて、あー、今日も糞RSS配信してるよ、ウゼぇameblo、とか言って何もしないのか?

ユーザーからしたらamebloだろうがRSSリーダーだろうがどっちが悪かろうが関係ないんだよ。RSSリーダーがちゃんと対応してればamebloに文句はねーんだよ。

無能でクズとか言いたい放題言ってるがよ、俺からしたら文句ばっか言って他人のせいにして仕事しないお前らの方が無能で無能で無能でクズだよ。

こういうの見てると今まで幸せ環境でしか仕事したこと無かったんだろうなぁって思うよ。

受注で、しかも孫受けの孫受けの案件とかしたことないだろ?

明らかに先方が理不尽で悪くても、こっちが尻拭いするなんてことは五万とあるんだよ!

自社コンテンツ持ってたり、エリートギークさんにはそんな世界は想像もつかないんだろうな。(もちろんギークのうち全員が全員そうだとは言わない)

お前らが無知とか無能とかクズとか言ったり、ソレ見て「その罵倒いいですね」とか嘲笑ったり、amebloキメェw、とか言って笑いものにするのも勝手にしたらいいけどな、これだけは言っておく。

その影で地べたに這いつくばって泥水啜りながら作業してるプログラマだっていることも忘れんなよ。

そして、そーゆープログラマにとってお前ら有名人のたった一言の迂闊な発言がな、グサっと刺さって抜けねぇこともあるってことを忘れんなよ。



だから最後にもう一言いっておく。

せめて言葉はくらいは選べよ。それくらいやってくれよ。

2007-09-16

もうすこしお勉強が必要なんじゃね

どっちが正しいとかはどうでもいいが に関する戯言。

いまさら食いつくけど

匿名ダイアリーを初めて見た俺がこのエントリを見て、なんか増田って人が滾ってるなあ、と思っちゃうのと一緒なんじゃね。色々話が混濁しているけど、そもそもの原因は、(この界隈での有名人を)自分が知らなかっただけ、という点だけでしょ。そこから、

こりゃこの業界が育たないわけだ。

とか、

他人の失敗に耐えられないのならもうそんなサービスやめてしまったほうがいいと思いますよ。

とかエクストリームすぎる方向に発散しちゃって、本人も収拾がつかなくなってる。

というわけで

無知で無能でクズ。アホでバカ。低脳でワーキングプア

ってのは、失敗に耐えて(非常に面倒な思いをして仕様上本来は必要がなくむしろするべきではない対策をする羽目になった) mala の苦言だと思うけどね。俺も mala に関しては、ブログをいくつか全読みして mala が脱ニートして LDR中の人になったってことぐらいしか知らないけど。

なんだかキチ○イな人が文句言ってるよぉと思ってる時点では、そもそもこれを字面通り受け取ってなんかいないでしょ。そこで終わってればよかったのに、わざわざ「周りが肯定的だったから」って思いっきり世間に流されて困惑して勝手に滾っちゃったのがこの結末。まぁ、

たしかにアメブロのやったことはかなりウザかったしキモイとも思ったけどクズ呼ばわりされるほどのことじゃないし何よりこの人の文章の方がひどい

という一文で、大体の認識のズレが見えてる。

結論としては

自分が無知だったって気がついた時点で引かなきゃだめでしょ。議論を進めるのに無知は罪。

あとね

もし自分が間違ったステータスコードを返すような処理を書いてしまってギークの人にめちゃめちゃに言われたらどうなるだろう?

自分の意志でものづくりしてる人だったらいくら叩かれてもめげたりしないよ。

2007-09-14

どっちが正しいとかはどうでもいいが

http://b.hatena.ne.jp/entry/http://mala.nowa.jp/entry/fa12686ffd

(元記事 http://mala.nowa.jp/entry/fa12686ffd

http://b.hatena.ne.jp/entry/http://junnama.alfasado.net/online/2007/09/livedoor.html

(元記事 http://junnama.alfasado.net/online/2007/09/livedoor.html

このmalaさんという人のことをあまり良く知らないので

「これは完全にエンジニア無知で無能でクズ。アホでバカ。低脳でワーキングプア。」

と書かれているのを見た時になんだかキチ○イな人が文句言ってるよぉとか思ってブクマ米見てみたらみんな肯定的でびっくりした。記事のコメント欄には言葉選べよ的なことを言ってる人もいたんだけどブクマ米はほぼ皆が肯定的だった。

え?なんで?たしかにアメブロのやったことはかなりウザかったしキモイとも思ったけどクズ呼ばわりされるほどのことじゃないし何よりこの人の文章の方がひどいので絶対叩かれてると思ったのに違ったわけだ。

んで不思議に思ったのでちょろちょろ調べていくうちにどうやら有名な人らしい。いわゆるギークと呼ばれる人とか。

なるほど、この人は本当は良い人で「無能でクズ」とかゆーのはいわゆるネタで、リアルではこんな発言をしないとても気さくな人なのかもしれない。

でもまぁそんなことは知らないよね。俺はmalaさんの友達でもないし知り合いでもないし、実際はすっごくいい人なのかとかどうとか俺にはわからない。

記事を見た印象でしか語れない。悪いけど、記事を見た第一印象はアメブロの行為が霞むくらいに最悪だったよ。だってさ、無知で無能でクズとかさ、いくらなんでも言いすぎだろうよ。リアルでお付き合いしたくない人ナンバー1だよ。

だから空気読めとか言ってる人もいるけどそもそもギーク界隈の身内ネタかどうかもわかんないしそんな空気が形成されてるかも知らないんだから無茶な話だ。

空気読めとか言うならそれこそmixiみたいな閉じた空間でやってくれよと。

んでこういうこと言うと多分釣れた釣れたとか言われて嘲笑されるんだろうな。

ギーク界隈ってみんなこんなんなの?web読んでる人のみんながみんな知り合いだと思ってるの?

ギークってのに憧れてたけど、こんなギークなら俺はなりたくない。(なれと言われてなれるもんでもないけどw)

馴れ合いばっかで正直キモイよ。

このアルファサードの人にも共感はできないけどそれについているブクマ米の方がもっと共感できない。

しかも嘲笑コメントに☆とかついててなんだよはてなスターってこういうキモイ使われ方するためのサービスだったのかよって思ってしまった。

ギークのみなさん、ふざけあったりするのもいいとは思いますが、もっと時と場所を選んだ方がいいと思います。

いくらネタでもあれはキモイです。引きました。

酒の席とか、身内同士のバカ話の中でポロっと出たものなら全然問題ないし逆に面白いとは思いますが、誰もが閲覧できるwebという環境でやる行いとは到底思えません。

アメブロHTTP素人であると言うのなら、あなた達は発言の素人だと思います。

最後にmalaさんの言葉を借りるなら、

「このように適切な言葉を選んで発言をするのに高度な技術と判断力が必要とされ、まさに職人芸。刺身の上にタンポポをのせる仕事と一緒にしないでいただきたい。」

と言えます。

以上、一増田のぼやきでした。



追記

これ書いた後に

http://kyanny.nowa.jp/entry/713ad5f4ab

を読んだんだけど

刺身タンポポが無能の代名詞みたいになっていて、そのフレーズを見かけるたびにお前が無能だ!と言われてるような気がして不愉快だ。奇しくもライブドア勤務だしさ。。

ですよね。不愉快ですよね、そんなこと言われたら。

何故その感情を、アメブロに対して「無知で無能でクズ」って言う前に気付けなかったんでしょうか?(いや、まあ、これはmalaさんの話であって、この人に言っても仕方のない事ですが・・・)

他人に向けてはネタでもなんでも平気で言うくせに自分に向けられたら不愉快だからやめろって、都合が良すぎますよね。

追記2

2007年09月14日 sunomononano この人は毒蝮三太夫の芸を見てもマジギレしそう

malaさんが芸人さんだとは知りませんでした。芸人さんの芸を見てマジギレとかマジかっこ悪いですね、俺。

・・・とまぁ皮肉はおいといて。

えと、本文中でも言いましたがそれはあなたがmalaさんという人がどういう人かを知ってるから言えるだけですよね?

予備知識のない人間からしたら「無知で無能でクズ」とか汚らしい言葉を平気で使う常識のない方だと思うのは至極普通です。

毒蝮三太夫がもし芸人ではなくて一般の人だとして、無能でクズとか言われたら確かにマジギレすると思います。

追記3

テレビという時点で大きなフィルターがかかってると思うのですが。sunomononanoさんはwebテレビも同じようなものだと言いたいのでしょうか?

webの場合は一般の人がそれこそ自由且つ簡単に情報を発信できます。だからそれがネタなのか本気なのかまったくわかりません。逆にテレビには色々な制約がつきます。なのでテレビではここまではないだろうなと大体の予測する事が可能です。

毒蝮を知らなくとも仕草や雰囲気でそれがネタであるかどうかは大体わかると思うのですが。

文章のみの場合と、映像があるかないかでは印象としてかなり差があると思うのですがどうでしょう?

というかちょっと話が脱線してきましたね・・・。こーゆー場合はあまりしつこく反応しない方がいいのかな・・。

追記4

2007年09月15日 oquno mala 「これは完全にエンジニア無知で無能でクズ。アホでバカ。低脳」まではギークとか関係なく、プロとして言われてもおかしくないんじゃないか

それはまったくもってその通りだと思います。話の内容自体は問題視していません。まさにその最後の言葉違和感を覚えただけです。

ブクマ米を見ているとどうもその辺をスルーしているみたいで、誰もキモイと思わなかったのかなと不思議に思ったわけです。

これがいわゆるスルー力というものなのでしょうか?

malaさんの無知無能クズ発言にはみなさんスルーするのにアルファサードの人の汚い言葉遣いには全力で反応しているところが俺個人的には気持ち悪いですね。

それこそ誰か仲の良い人とかがmalaさんにあれは言いすぎだよと注意してあげなかったんでしょうか?(もしかしたら注意してるかもしれませんが・・・)

追記5

2007年09月15日 yappo yappo malaはamebroのfeed読んでる全員に対して行った多大な迷惑行為を全力で叩いただけ。おっさんはmalaのそれを表面的に受け取って売名行為をしたかっただけ。

そうですね、前者は完全に同意します。確かに迷惑でしたし、ウゼぇとも思いました。

でもやはりあの最後の一文にはまったく同意できません。これはもはや技術者としてじゃなく人としてどうなの?というレベルです。

界隈ではツーカーでその辺空気読めばわかるだろみたいな流れがあるのかもしれませんが、記事をみる殆どの人がそんなこと知らないと思います。みんながみんなmalaさんを知ってるわけじゃないんです。

それに売名行為うんぬん言う話も良くわかりません。アルファサードの人が最初にあげた記事を読みましたが売名行為だとは感じませんでした。

大体こんな発言してこの人になんのメリットがあるんでしょうか?

「優秀な技術者だとしても言葉遣いは気をつけろ」ぐらいの内容だと解釈したんですがギークの方々は「あぁこいつ売名行為のために噛み付いてきてるな、キモイ」という発想しかできなかったのですか?

売名行為売名行為だと言ってますが、じゃああなた達がブクマしなければ誰も気付かなかったんじゃないでしょうか?

それにギーク達に嘲笑されて売名が成功したって負のイメージしかつかないじゃないですか。

「おお、アルファサードって会社はたとえ優秀な技術者でも言葉を選ばないやつには厳しい会社なんだな、そーゆー会社なら信頼できる!仕事を頼もう!」という風になるとでも?売名行為が成功するってこういうことですよね?

馬鹿馬鹿しいですよ。アルファの人は単に思ったことをブログで発言しただけでしょう?深読みしすぎじゃないですか?

malaさんに批判的な記事を見つけた→なにコイツ、空気読め、キモイと思った→ブログ書いてる人が社長と判明→売名行為だ!

っていう単純な思考が見え隠れして気持ち悪いです。

こんなこと言いたくなかったけど、この際だから言います。

さすがに自惚れすぎですよ。恥ずかしくないんですか?

優秀な技術者ってみんなこうなんですか?

なんか想像してたのと違う。

・・・なんすかね、コレ。勝手に期待しといて勝手にヘコんでんじゃねぇってやつですかね・・・。

追記6

まずこれだけはハッキリしておきたいのですが、俺は初めからずっと言ってる通り、アメブロの迷惑行為は最悪だとは思っています。確かに開発者ではないので開発者視点でものは語れませんが。

2007年09月15日 KoshianX KoshianX web それはおもいっきり勘違い。間違ったステータス返すことでどれだけ周囲に迷惑かけるか想像できてないでしょ? 素人さんが「RSSリーダーの表示がおかしいんです!」とかRSSリーダー開発者クレーム殺到とかありがちでしょ

なるほど。ということはあなたは「無知で無能でクズ。アホでバカ。低脳でワーキングプア。」という発言はネタでも何でもなく本当の意味で心底そう思って発言したといいたいわけですね?

間違ったステータスコードを返す人は、その人が今までどんな生き方をしていたとしても「無知」で「無能」で「クズ」で「アホ」で「バカ」で「低脳」で「ワーキングプア」だと言われてもなんら反論できない程の愚行だといいたいわけですね。

であればもう何も言うことはありません。

人間誰しも始めは何も知りません。勉強したり経験を積んだりして知識を蓄えてきます。良くわかってないまま成長したり、たまたまある部分の知識が抜けたまま成長したり人によって色々あると思います。

そして失敗を犯したりもします。そういう時にギークさん達は罵詈雑言で攻め立ててそーゆー人を摘み取っていくわけなんですね。

こりゃこの業界が育たないわけだ。個人でも企業でも社会でも失敗を許さない風潮というのは失敗が怖くて何も出来ないという悪循環を産みます。

他人の失敗に耐えられないのならもうそんなサービスやめてしまったほうがいいと思いますよ。RSSリーダーというのは他人(アメブロ等)に依存したサービスなんですから、これからも同じようなことは起きると思います。

無知で無能でクズが配信するかもしれないRSSを優秀なあなたが相手にする必要はないでしょう。

全体的に皮肉っぽい文章になってしまいました。それは申し訳ないと思っています。

ですが、なんでしょうか。胸にもやもやしたものが残りました。

多分自分と重ねた部分があるからかもしれません。

もし自分が間違ったステータスコードを返すような処理を書いてしまってギークの人にめちゃめちゃに言われたらどうなるだろう?

もし、これから自分がいわゆる他人から見てギークだと言われるような存在になった時に、こういうこと言っちゃうようになってしまうんだろうか?

今の今まで無能でクズなんて言葉使ったこともないし、そういう言葉が必要になるような場面も想像つかない。

たかだかWeb上での暴言にどんだけ繊細なんだよお前はという人もいるかもしれませんが、これが2chのような匿名の人に言われるのならまったく問題ありません。

名の知れたギークの人に言われるのとは天と地との差があると思います。

もうこの記事に追記はいたしません。これで終わりにします。

俺はネタでもなんでも失敗を犯した他人に対して「無知で無能でクズ」なんて言葉を使わなくてもことの重大さに気付かせつつ次は頑張ろうと思わせるような言葉を選んで発言していくための努力を惜しみません。

名も無い一技術者のままであろうと、今後有名な技術者になったとしても。

自戒の念を込めて。

追記7(まとめ)

もう追記しないといいながら追記する人間の性。

後で自分で書いた記事を読み返してみたら追記の量が多すぎていったい何を言いたかったのかよくわからなくなってるので最後にまとめだけしておく。これで最後。俺の主張はだたこれだけのことだったんです。

これらの気持ち悪いと思った理由については記事本文および追記1-6に書いてるので割愛します。

以上です。

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