  |
はてなキーワード: rest apiとは
実装を進めて、あとの方で「やっぱこうして」といって後戻りの工程が発生すると穴を掘って埋めるような感覚になる。
こういうのは効率性を低下させるので、関係各位と調整して情報を揃えたほうがいい。
もし情報が限定的にしか揃わない場合は、非常に簡易的なプロトタイプを触ってもらって、「こうしたほうがいい」という声をもらう。
情報として基本的なのは、UI設計とデータ設計だろう。これらが煮詰まった段階でデータフローのシーケンスを特定していく。
例えばUIの担当者が外観の設計を渋っているときは、入出力だけでも特定し、その入出力のプロトタイプを作っておいたほうが良い。
自動計量炊飯器 https://b.hatena.ne.jp/entry/s/kaden.watch.impress.co.jp/docs/news/1455775.html 先行体験（するための購入する権利に）当選した。
しかし冷静に考えてみるとコンセプト含めて微妙な気がしなくも無い人柱に46k円はなかなかチャレンジングで一瞬冷静に戻ってしまった。
ということで改めて使用シーンを考えてみて、以下の観点からやはり面白そうなガジェットではあるので素直に買ってみようと思う。
希望としてIFTTTと連携するとかREST API公開とかをパナに求めても無理そうだけど、サポートしないが用意はしてやるので好きにしろみたいなのがあるといいな。HTRCCP(Hyper Text Rice Cooker Control Protocol)も欲しい。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
はっきり言って、北米の小規模開発者の訴訟も、日本の公取委との合意も
Appleから大した譲歩引き出せてないのに大幅譲歩した、みたいな論調になってんの気持ち悪い。
「今まで頑として譲歩しようとしなかったAppleからほんの少しでも譲歩を引き出せただけで大成功！」っていう報じ方には見えないものばかりだ。
北米の小規模開発者の集団訴訟の件でよく言われる「Appleがアプリ外決済を認めた！」って、元から認めてなきゃリーダーアプリ何も出来ねぇだろ。
アプリ外課金認めてなきゃ、Kindleアプリは今まで何を表示してたんだよ。
アレで得られた譲歩は「アプリ外の決済方法についてアプリの外でメールなんかで通知してもいい」ぐらいでしょ。
こんな下らない譲歩をよくあそこまで扇動的に報じることが出来たもんだ。
日本の公取委との合意に関してはどうなるか若干不透明だけど、「公式サイトへのリンク一つ」がどういう扱いになるかにかかってそう。
REST APIを単一アドレスにしてPOSTで書籍情報投げるようにすれば容認されるのか、
それとも厳密に単一アドレスのハイパーリンクを設置することが許されただけなのかによって結果が大きく変わる。
Apple側としては後者に寄せたがってるだろうけど、公取委側がきちんとそれを止められたのかが正直不安。
今の政府組織ってIT関連の施策まともに打てると信じられる要素何もないから、
Apple側の抜け目ない合意文書の真意を見抜けず実質無意味な合意文書にハンコ押したんじゃないかと思っちゃう。
今Webでニュースを報じる側としてはPV稼がなきゃならん以上どうしても扇動的な記事書かなきゃならんのだろうが
そのために事実を捻じ曲げてんの見ると「確たる収入源がないと人はどんどん低俗になっていくんだな」という感想しかない。
小規模開発者の弁護団とか公取委とか、当事者が成果を強調しなきゃならないって事情もあるんだろうが、
報じる側が気取っていられる程収入に余裕がなくなったせいで、報道が根腐れ起こしちゃってるように見える。
別に「Web以前の報道は品行方正だった」なんていうつもりはないけど、Web以降明らかに質が低下してるように見えるのよな。
だれでも報じられるようになった結果生み出されたゴミに埋もれたって側面もあるだろうけど、個々の品質劣化も視界に入るようになったしな。
なんというか、これから先は「情報が正しいかどうか」ではなく「情報を信じるかどうか」しか判断できない時代が来るのかもなぁ。
日本の超大手企業(繊維系)の内製システムのエンジニア採用を受けて落ちた時の記録
虚実織り交ぜて書いてるので真にうけないように
受かった人の話を聞いてみたい
割と普通の内容だったがRubyのコードを見せられたときは面食らった
サービスのアーキテクチャ設計するときに気をつけていることは何？
セキュリティ面で気をつけていることは何？
唐突にRubyのコードを見せられ、このコードの悪いところはどこですか？
サービス規模の割に社員数が少ないけどどんな編成になってるのか
なんでもクラウドベンダーの特定技術に縛られたくないからKubernetes使いたいみたいなことを言っていた気がする(そういうための技術じゃないけど)
なぜアプリエンジニアと面接したか不明(当方の専門はバックエンド)
経営陣がクラウドの予算を出さないが24/365守れと言われたらどうする
交渉してだめだったら
24/365関連の質問です。サービスをスパイクさせないためにはどうしますか？
あなたの考える最強のバックエンドアーキテクチャをおしえてください
質問を変えます、月の予算1億円もらったらどんな構成にしますか
// 過去にアプリ開発をしたことがあったのでアプリ開発について質問を受ける
iOS/Androidのアーキテクチャを設計するとしてどこまで同じ技術を使うように強制しますか
SwiftUIはメモリ食いまくりで大規模アプリでは使い物にならないことですね(ドヤ)
SwiftUIではメモリ食いすぎてインフィニットスクロールが使えません(ドヤ)
先ほどSwiftUIについての質問を受けましたが御社のアプリではSwiftUIを導入されてますか？
外部協力会社とサービス開発をしているということだけど今後社員比率をあげる予定はあるか
去年4月に新卒入社した会社を今月末に退職して4月からフリーランスになることに決まった。
備忘録として、また他のフリーランスになりたい人役に立てるために現状を残しておく。
Web系のベンチャーでインターン(マーケター)したところ面白くてずっと働いてたら中退することになった。ちなみに会社は潰れたのでそこで働くことはできなかった。
情報系の大学院だがWebサイト構築できるわけでもなくサーバーサイドをガリガリかけるわけでもなかった。アルゴリズムは結構書いてて、2分探索木とかナイーブなダイクストラ法を実装できるレベル
エンジニア派遣の会社に入った。理由としては研修がしっかりしてて採用担当の人が賢そうでネットで悪い評判が見当たらなかったから。
エンジニアになりたかったが就活時期が就職の2ヶ月前から始めたため大手に入ることができず、Dodaとかリクナビで適当に「エンジニア 未経験」で出てきた会社に入った。
本当は自社開発の会社に入りたかったがスキルに自信がなかったため未経験歓迎の会社しか受けなかった。
初任給は300万くらい。正直言って自分の学歴からエンジニア派遣の会社に入ることは屈辱的だったが結果としてこの選択は非常に良かった。
3ヶ月の研修を経て現場に行ったのだが良い人に囲まれてガシガシ開発をできることは最高の経験だった。おまけに研修も少人数で行えたので非常に楽しく、良き友人に恵まれた。
初年度はとにかく勉強を頑張った。
平日は必ず定時に退社して毎日4-5時間勉強。休日は8時間勉強。日曜日は休みでフットサルして散歩してた。
その結果大学院の時はできなかったWebサイトの構築、サーバーの構築、REST APIでのサーバー実装くらいは余裕でできるようになった。
現場で使っている技術がサチってきて、学べることが少なくなってきたので営業に現場の交代を依頼したがのらりくらりとかわされたため退職を決意
ちなみにこれは営業が全て悪いわけではなく取引先に一方的な都合で派遣を解除することは難しかったり、次の現場の候補がなかったりといろいろな事情があるため一概に会社が悪いとは思っていない。
フリーになって初めて知ったがこの単価からエージェントの手数料と消費税が引かれて大体63万になるらしい。そこから社会保険とか諸々引かれて、、、一体いくらになるのだろう。
来年の給与がボーナスなしで月38万と聞いていたので正直会社辞めなくても良かったと若干後悔している。
自分の会社は自信を持っておすすめできるが業界全体としては正直わからない。
合格をもらった会社の中では研修なしで1年間携帯販売の仕事をしながら自社に帰って勉強しながらエンジニアを目指すとかいう意味不明な会社もあったので会社によってピンキリ
また現職の会社は一部上場企業の子会社でコンプラしっかりしててやたら他業界からエンジニアを目指してやってきた高学歴ばっかで基本国立大学以下はいなかった気がする。
そのおかげで開発案件しか派遣先にないらしく良い経験をできたがブラックでまともな研修を受けられない会社もあるらしいのでなんとも言えない。
間違いなく言えるのはエンジニアを目指すのは東京に来た方が良いということ。
自分は運悪く研究室に恵まれず十分な指導を受けられなかったり、軽いパワハラを受けていたので大学院は全く楽しくなかったですが企業は成果を出すことを求められるので社員のスキルを上げる合理的な理由があり研修を行ってくれるし何より同じ目標を持った仲間とチームで開発することはかけがえのない最高の経験になります。
また、大学や研究室は学力のみのフィルタリングで良いひともいれば嫌な人もいますが企業は採用段階で強くフィルタリングがかかるので正しく会社を選べば良い人しかいない職場で気持ちよく働けます。
https://anond.hatelabo.jp/はてなid/
っていうURL（もしくははてなidのみ）を渡したら、わたされたidの増田を一通りなめて、ブクマ数順、トラバ数順に表示することできる？
できるならやりかたおしえてほしい
つーかもしかして増田の内容ってエクスポートとかできないのか・・・？
増田がもはやマイブログになってる自分にとってはかなりきびしー
http://developer.hatena.ne.jp/ja/documents/bookmark
使えそうなAPIってこの３つくらい？
はてなブックマークを参照、投稿、編集、削除できる API です
GETリクエストでブックマーク数を取得できるシンプルなAPIです
ブックマークされたエントリーのタイトル、ブックマーク数などの情報をJSONで取得することができます
↑に加えてたぶん増田ログイン状態で取得とかやんなきゃだから、認証系のAPIも使うっぽい感じ？
http://developer.hatena.ne.jp/ja/documents/auth
とりあえずテスト続き
http://developer.hatena.ne.jp/ja/documents/bookmark/apis/getcount
ここみて、自分の増田全部でトータルブクマ数だせるのかなとおもってやってみたこと
例えば特定のブログで、そのブログが全体で何件ブックマークされているかを取得することができます。(本API は 2018年06月05日に追加されました。)
http://api.b.st-hatena.com/entry.total_count?url=http%3A%2F%2Fwww.hatena.ne.jp%2F
http://api.b.st-hatena.com/entry.total_count?url=https%3A%2F%2Fanond.hatelabo.jp%2Fほげほげ%2F
ってやってアドレスバーに入れてッターンしてみた
結果・・・
{"url":"https://anond.hatelabo.jp/ほげほげ/","total_bookmarks":0}
ですよねーーーーー
ダメでした；；
某キャラクターカフェの予約が戦争状態なので、自分のスキルをお金にしようと思い
Twitterで1席500円で予約代行を募ったところ、DMでめちゃくちゃ叩かれました。
受け取ったメッセージの中で一番多かったのが、
「明確な違反です！」「お金を取るのはだめです！」だったのですが、
また、予約代行でお金をいただくのがアウトなら、
予約を取るための時間や技術を、お金を払って肩代わりしてもらうことができなくなるので、
世の中にあるレストラン・ホテル等の予約代行業は軒並みアウトだと思っています。
予約システムのREST APIにPOSTリクエストを2発投げるだけなので、
DMで怒ってきた人に「明確に違反しているということなので、どの点が何に違反しているのか教えてほしい」
ときいても、「常識的に考えたらわかるでしょう！」「真面目に予約を取ろうとしている人に失礼です！」
といった感じで、明確な答えを出してくれる人は一人もおらず、
どうしても「お前のやってることが気に食わないから潰す」
と言っているようにしか思えませんでした。
Twitterで「代行費」で検索すると、普通に代行費をとって何かしらの
グッズ・チケットの購入を代行している方が山程いるのですが、
周りの人を総動員して予約を手伝ってもらっていて、
それと何が違うのかよくわからなくなりました。
単にお気持ちヤクザさんに怒られたのか、明確に何かに違反しているのかわからずもやもやしているので、
昨日おとといと増田もはてブも落ちていて、今日見てみたらむちゃくちゃびっくりしました。
読んでいただき本当にありがとうございます。
普段増田に書いてもブコメ0トラバ0だったこともあり、やけくそで多少盛った自己紹介をしたことは謹んでお詫び申し上げます。
以下追記です。
本当にそうですね…。
予約したい人の名義で予約をとるつもりだったので、譲渡に当たらないと端から思い込んでいたのですが、
ご指摘の通り、譲渡に当たるかどうかは運営会社が決めることですし、ルールに違反してまで強行する気は毛頭ないです。
というか、もう仮に許可がもらえたとしても「運営は許しても僕は私はお前を許さない」系の
こちらの理解が及ばない人にめっちゃ叩かれるのが目に見えてるので手を出す気が失せました…。
答えは知りたいので、運営会社には次の内容で問い合わせました。現在返事待ちです。
DMで叩いてきた方も別の人に予約を依頼しているパターンが多かったので、代行がアウトになってしまうと自分達に都合が悪くなるから
二次創作するときの「公式に許可を取りに行くな、グレーゾーンのままにしておけ」って話と似てますね。
これは想像力が足りていませんでした…！勉強になりました。ありがとうございます。
レストランについては、某旅行会社に海外のレストランを予約してもらったときに
「電話がつながるところならどこでも代行できますよ～」と言われたので、
特に縛りがないのかなと思いました。国内はわからないですが…。
実際には、ログイン等のユーザーの認証認可が必要な行為なしで、誰でもアクセスできるformに予約情報を投げる動きになるため、
以下ページのいずれにも該当しないと思っています。
月5000円位の儲けにしかならない程度を想定していたので、さすがに納税までは考えていませんでした。
20万円超えたら確定申告しますが、冒頭で述べたとおりもう手を出す気が失せました。
どこかの頭のいい17歳女子高生がこういう需要をすくい上げた上でみんなが幸せになれるようなビジネスモデルを考えてくれればな～
大企業。名前だけならたぶんほとんどの人が知ってる。毎日定時に帰れて、週休二日で、有給もフル消化できて、給料も福利厚生も申し分無くて、寂しい時は社内イベントや勉強会に出てワイワイできて、仕事もそこそこ面白い。だけどもうダメかもしんない。
俺はエンジニアだ。うちは IT 企業だ。俺はエンジニアとして働くつもりで入社した。面接でもそう言ったし、先輩にも上司にも主張した。衝突も多かったけれど、概ね希望は通ったと思う。今の仕事は面白い。でも、それでも、もうダメかもしんない。こうしてお酒を飲みながら不満を垂らしちゃうほどに。
スーツ強制である。意味がわからない。あんな窮屈な服をわざわざ好んで着るほど俺はマゾじゃない。
営業マンやオフィス街に勤めるビジネスマンだってんならまだわかるけど、違う。田舎に構える拠点だ。俺たちはエンジニアだ。仕事しやすい格好であるべきだ。だからといってさすがに裸は非常識だが、ジーパンくらいはいいじゃないか。
たまにお客さんやお偉いさんが来る時もあるけど、そんなの応接室で応対する奴だけ正装すればいい。なんで俺たちにまで押し付けるのか。本当に意味がわからない。マゾという性癖を押し付けたいの？
ネットニュースは見れるくせに、Twitter は見れない。技術用語で検索して情報収集できることを知らないのかよ。
Stackoverflow や Quora や Qiita も見れない（知恵袋は見れる）。GitHub も Bitbucket も、そしてはてなさえもだ。え？IT企業だよね？何の冗談だよ。全然笑えないぞ。
「情報漏えい対策です」だって？だったら POST だけ禁止すればいいじゃん。一部のサイトはそうしてるじゃん。情シスなのに GET と POST の違いもわからないの？
とにかく不便で不便で仕方がない。管理職は「自分のスマホで見ろ」「制限解除した専用タブレットで見ろ」とかほざいてるんだけど、なんでいちいち PC から離れてそっち見なきゃいけないの？コピペしたい時とかどうすんの？効率って言葉知りませんか？何なの？マゾなの？
ウォーターウォールが常にダメとは言わない。ただウォーターフォールは昔のやり方であって、少ない人材でスピードも求められる現代ではだいたい役不足だ。にもかかわらず、馬鹿の一つ覚えみたいにウォーターフォールで開発しようとする。
テストコード書いて効率化して暇を持て余して改善に勤しむ俺よりも、いっしょうけんめい（笑）ワード使ってコードを日本語にひたすら翻訳するという詳細設計書執筆に勤しんでる奴の方が評価されてるという現実。第一ウォーターフォールに従うなら先にコードができてるのもおかしいじゃねーかよ。
ウォーターフォール続き。開発審査といってこれを通過しないと先の肯定に進めない関所みたいな審査があるんだけど、これがまた冗談みたいに面白い（笑えない）。何十年も（何年も、ではない）前につくられた基準で、かつ無理矢理定量的に解決しようとした体系をしていて、結果、
「x時間に至ってない？それはおかしい。x時間になるまでレビューしろ」
「x時間超えてる？それはおかしい。なんで超えたのは理由を説明しろ」
なんてことが起きている。何なの？ソフトウェア開発がそんなに単純にいくと思ってるの？そんなはずない。みんなわかってる。だけど逆らうこともなく、おかしいとも思わず、ただただ過剰な仕事を投入したり、数字いじりと作文に勤しんだりする。一体何と戦ってるんだよ。
ちょっとした資料でもパワポが強要される。テキストで書くと渋い顔をするし、他部署や他拠点、部長より上向けの資料となると絶対に OK が出ない。
独自フォーマットじゃねえよ。Markdown 知らないの？別に Markdown 覚えろって話じゃない。ちゃんと見易いテキストで書いてるだろ。分量的にも、話題的にもこれで十分だろ。なのにわざわざパワポなの？何がしたいの？パワポ萌えなの？勝手にやってろよ。俺たちまで巻き込むな。
PCとディスプレイは会社側が用意したものしか使えない。Windows 強制。メモリとかCPUは家電量販店で売ってるレベル。いやそっちの方がまだ高性能かも。おいおい、総務とかじゃないんだぜ？エンジニアですぜ？開発マシンだよ？こんな貧弱なマシンでどうしろって言うの？
キーボとマウスとディスプレイ枚数が自由なのがせめてもの救い。といってもディスプレイは会社支給品なので一人あたりどう頑張ってもトリプルだけど。
サーバーで仮想マシン動かしてそっちで開発しようとか、むしろ開発用のハイスペックマシン手に入れようとか画策するんだけど、無理。調達できない。壁が二つ。
上司の壁。「何贅沢言ってんの？」 贅沢じゃねえよ。それ営業マンに向かって「車？何贅沢言ってんの？（原付あるだろうが）」て言ってるようなもんだぞ。
会社の壁。やたら承認やらエクセル申請書やら冗長で数日じゃ終わらない。ちょっと記入ミスってたらやり直し。融通の利かないお役所仕事。そもそもお金が無いからそんな調達できないんだってさ。無いことはないだろ。利益出してんだろうが。その金はどこ行ってるの？お偉いさんがガハハとかっさってんの？
結局、今部署にある分でやりくりしなきゃいけない。だいぶ昔から使ってるやつだから古いし、キャパも限界。使わないマシンを落とさないと他が使えなくて、そのためにみんなに使用状況聞いて回るとかしている始末。おかしいだろうがよ。
え？クラウド？「クラウドに企業秘密置くなんて何事だ！」だってさ。だったら紙で仕事してろよハゲ。
必ずインストールして常駐させるソフトが結構ある。特にセキュリティ系。中には Windows Update みたく動作に支障を及ぼすものもある。お前自身がウイルスじゃねえかよと言いたくなるレベル。
あと全体的に実装が稚拙なようでメモリも CPU もやたら食う。ソース見せてもらえないから何とも言えないけど、初心者がゴリ押しで書いたみたいな臭いがする。これで何百、何千の人間の、いったいどれだけの時間を無駄にしているんだろう。
インフラがとにかく弱い。メンテナンスは日常茶飯事だし、入社年度とか拠点とかでアクセスしていい時間帯を分けるようアナウンスするし、24時間稼働じゃないし、稼働するにしても昼休憩とか夜間とか制限かけるし。自社のインフラさえままならない企業にいったい何ができるというのか。
本当に力入れた方がいいと思う。どれだけ損失してると思ってんだよ。お偉いさんのイベントで主張してみたりもしたけど、俺が浮いただけだった。こういうことに関して鈍感なのがデフォなのだ。
社内システムはほとんど IE しかサポートしてない。バージョンまで固定する始末。UI もレガシーだし、UX も全然考慮されてなくて、フォームを何十個もずらずら並べたみたいなページが普通に登場する。
SVN である。これでもまだマシだ。いや SVN も相当にオワコンだけど（Git 信者が何を知ってるって？いやいや Git 知らないだけでしょ。gitignore が無い時点でどれだけレガシーなのかがわかりませんか）。
ひどいと VSS とかいう化石だったりする。VSSて何ですか？だよね、知らないよね。調べてみるといいよ。面白すぎて笑えない。
今上に立っている人たちが残業何十時間何百時間当たり前の世界でバリバリ頑張ってきた人たちだから、そういう価値観が蔓延している。残業40時間くらい何とも思わない人種である。いや40でも十分多いから。
物理的に仕事が多いならわかる。本質的に難しいことしてるならわかる。残業しなきゃままならないシチュは存在する。でもそんなの見たところ一握りだよ。大半はただだらけてて怠けてて非効率的で無知なだけ。
いや、無頓着というべきかもしれない。たとえばつい先日こんなことがあった。レビューで（俺はレビューア。他にもたくさん）、レビューイがブラウザからファイルをダウンロードした時にブラウザなのかダウンロード先なのかどこかおかして、ブラウザがフリーズしたのね。イラっとするじゃん？と思ったら、したのは俺だけだった。数十秒くらいは続いたのに、俺以外はみんな平気な顔してた。平然と待ってた。そういうことに無頓着なんだ。プログラマの三大美徳を備えろとまでは言わないけど、そこまで無頓着なのは社会人として、エンジニアやビジネスマンとして、どうかと思う。
俺は巻き込まれたくないからうまく立ち回っていて、帰ろうと思えば毎日定時で帰れるが。この体質はほんとどうにかした方がいいと思う。
英数字とスペースを全角で打つのはやめろ。それが許されるの小説だけだ。
インデントはタブを挿入すること ← 俺はスペース派だが、まあわかる。規約ならしゃーない。
「従わなければいいじゃん」 俺もそう思ったよ。でもね、みんなね、レイアウト整えるのにタブ文字を入れやがんだよ。わかるかい、タブ4文字にしなきゃレイアウトが崩れるってことだよ。おかしくない？レイアウトはスペースで揃えよ。タブが許されるのは行頭のインデント部分だけだよ。
この件について戦ってみたことがあるけど、誰一人として賛同は得られなかった。俺は自分勝手な人間との烙印を押されただけだった。エンジニアとして主張すればそうなっちゃうのがうちなのだ。
この件については宗教論争的なこともあるから最悪引き上がる覚悟もあった（それにぶっちゃけ手元のエディタやツールで変えればいいことだし）。でもどいつもこいつも真面目に考えることなく、俺を一蹴した。俺が嫌いだから？何大人げないことしてんの？小学生かよ。意見を見ろよ、中身を見ろよ。
こんなことがあった。
オンプレで立ち上げてるサービスに対して REST API を勝手に使ったら怒られた。曰くシステムがダウンしたらどうなるんだと。業務停止するだろうがと。
言ってることは正しいけど、だったらエントリポイントを閉塞しておけよ。あるいは注意で REST API 使うなと書いておけよ。REST API をデフォでサポートしていて、何の注意や閉塞もなく解放されているなら、それは自由に使っていいってことだろ？（もちろんだからといってリクエストをバーストさせていいわけじゃないが）。悪いのはそんなことも知らなかった無知な管理者だ。責任転嫁するな。
ちなみに閉塞案と注意追加案と提案してみたが無視されている。もちろんそれらを行う権限は俺にはない。
チャットの意義は Pull 型コミュニケーションができることだ。受け取った側の都合で返信できることだ。送る側も、そのことを前提とした上で、期限に余裕のあることを送るのだ。
このことを知らない人があまりに多い。とにかく彼らは口頭を好む。え？あんたら、忙しいよね？むしろ俺は配慮してあげてるつもりなんだけど。口頭で割り込まれることでどれだけ集中を阻害されているかがわからないんだろうか。
まあ俺はいいけど。集中削がれて非生産的になって遅れるのはあんたらだから。俺には関係無い。もちろんそのせいで俺にまで影響が及ぶのだとしたら、そこは全力で反抗する。そういえば以前、この件で上司の上司に対してチャットでみんなに意見を尋ねてみたら、問題行動として垢BAN食らったっけなあ。その部署からは異動しました。
C言語手続きプログラミングマンがあまりに多い。OOPを使っただけで、Ruby スクリで実装しただけ異分子扱いされて「そういう最新技術を誰もが知っているわけじゃない」「自分が知っているからといって無闇に適用するにはやめろ」とか言われる始末。最新技術って。ジョークだったんだろうか。あの時は思い切り笑った。その先輩とは今でも疎遠だ。すれ違っても挨拶してくれない。
まあこれは部署や部門の問題だと思うけど。たとえば OSS で食べてる部隊ではそんなことはない。
昇進するための要件として資格取得がある。公的資格だけじゃダメで、社内独自の資格も必要なんだけど、この資格たち、試験でどうでもいい自社製品うんちくばかり問うてくるものである。はてなを例にするなら、創業時メンバー全員（一人かもしんない。知らん）のフルネームを答えよとか、創業日を答えよなど。
それ、覚えて意味ある？何がしたいの？愛社精神擦り付けたいの？そんなことしても逆に離れていくだけだと思うけど。違うかな。じゃあ何のためだろ。全く見当もつかない。それくらいに不可解だ。
ソフトウェアを新しく使用のにいちいち承認が必要とかいうふざけた制度があった。ソフト使うのって、エンジニアにとっては日常茶飯事じゃん。いちいち承認してたら進まないだろ。
それでもルールなら仕方ない。俺は何十という承認依頼を送った（ちなみに部長以上のお偉いさんが承認者になるという慣習がある）。反応が悪いし、仕事が進まないので口頭でも催促した。一蹴された時は「ならもっと上の人に掛け合います、XXさんが相手にしてくれなかったので来ましたって」的なことを言ったりもした。
結局、俺の部署では「なるべく新しいソフトウェアは使わないこと」「どうしても使いたい場合は自己責任で導入すること」「もちろんウイルスチェックはちゃんとしてね」「実績のあるソフトだけ使ってね」みたいな緩いルールが新設されることでケリがついた。
今でも多くの部署が承認制のままだろう。みんなどうしてるんだろ。それで仕事になるの？
うちは IT 企業なのに、リテラシーに明るくない人がいる。たとえば Wiki の書き方も知らないような人がいる。そういう人が部下を仕切っていたり、社員を支えるスタッフ業務に携わっていたりする。
エンジニアとしてより良いやり方を提案しても、導入しても「難しそう」と一蹴されるばかり。そもそも、ここまで上述してきたことに対してピンと来ることさえない。
厄介なのは、会社そのものがそういう人達に足並みを揃えようとするところだ。だからエンジニアにとっては物足りない、窮屈で、非効率的で、むしろ邪魔にしかならないようなシステムや仕組みや施策ばかりが降ってくる。元を辿れば煩わしいセキュリティソフト群や承認フローの多さも、一部のバカが何かしでかしたせいだ。
一部の人間が足を引っ張っている。大企業であるということ、図体が大きいということは、そういうことなんだと思う。そうするしかないのだろうか？個人的には、エンジニアとそれ以外に二分して、前者には前者のインフラなり体制なり整えればいいと思うんだけども。
うちの会社の連中は、彼らはエンジニアではない。思えば余暇で技術的な話をすることが一切無い。彼らにとって技術は手段でしかないのだろう。エンジニアとしての矜持というものは存在しないのだ。
たとえるならママチャリに乗っている人達みたいなものだ。ロードバイクに乗る人からすればママチャリは手段としてありえない。ロードの方が何倍も早いし、移動範囲も広がる。けれどママチャリ乗りはロードには乗らない。そんな世界があることをそもそも知らないし、知っているにしても努力してそこまで至ろうとは思っていない。今のままで十分だと思っている。
同じなのだ。彼らもまた今のままでいいと思っている。エンジニアリングのエの字もわかっていない。無論、ただのママチャリ乗りならそれでもいいんだけど、俺たちは IT を生業とする会社だ。ロードレースでメシ食べてるようなものなんだよ。なのにママチャリのままなんだ。どう考えたっておかしい。それで勝てるわけないだろ。この先どうすんの。今はたまたま誰も走ってない道を走ってるだけだ。そういう道も着実に少なくなってきているし、ママチャリで頑張って登ろうとするゴリ押しマン要員も減ってきている。
他にも挙げればいくらでも出てきそうだけど、疲れたんでこの辺で。
俺も偉そうなこと書けるほどのエンジニアではないし、ちゃんと読みやすいよううまく書けたか自信ないけど、それでも書かずにはいられなかった。
wordpress最盛期。あの案件もこの案件もWordPressを使って、プラグインましましjqueryましまし脂マシマシな納品が星の数ほど生まれていく。「プラグインが最新バージョンに対応しないので、本体のバージョンアップができません」といってセキュリティホールだらけのwordpressが放置される。アホかと、バカかと。
フロントエンドはhtml,css,javascriptでつくるものだよ。expressをみて「javascriptでバックエンド書くの？気持ち悪い」っていってただろ。それと同じだ。いつまでphpでフロントエンド書くつもりだよ。phpで動的生成し続けるから、いつまでもwp headでwordpressのサイトってバレてアタック受けるんだよ。とりあえずurlの末尾にwp-adminってつけて確認されるんだよ。
分離しろ、分離。wordpressの管理画面が悪いとはいわない。あいつはいいやつだ。けど、wordpressでフロント書く必要はない。wordpressもrest apiだしただろ。更新はwordpressでやって、その情報をapiで取得してきたらいいんだ、それでいい。
wordpressでテーマをつくるのがキャッチだった頃からもう6年はたった。6年前といえば、Windows 7使ってた頃だよ。ヒカリエまだできてない。そんな頃のやり方つかって「これがスタンダードです」とかいってクライアントをだまくらかして楽しいか。さっさと2017年に追いつけよ。
エロが好きです。
ボクはDMM.R18のヘビーユーザーなのですが、どうしても自分の好みの中だけで、グルグル回ってしまい、
世の中にAVは山ほどあるはずなのに、知らないなんてもったいない！もっとたくさんのエロに出会いたいという思いがあって日々悶々としていました。。
そんな中、AVというのは毎日の気分によってオナニーしたい見たいものが違うわけだから（例えば毎日食べたいおかずが違うように）、
今の自分の気分を簡単に答えれば、それに対してオススメのAV動画を紹介してくれるというサービスはどうだろう？とモヤモヤと考えていました。
ある日、会社の人に相談したら、それ「いいね！」ということになって、「そういえばDMMのAPIってのが公開されたから、それ使ってできるんじゃね？」ってことになり、
本格的にサービス開発を行うことになりました。
そしてこの度無事リリースすることができました。
「今夜のおかず」
３つの質問に YES / NO で答えるだけで、今のあなたに最適なアダルト動画を紹介するサービスです。
・フレームワーク：express（node.jsのフレームワーク）
・クライアント：jQuery、CoffeeScript、SCSS
・ビルドツール：grunt
node.jsは少し趣味でやった程度で、今回やってセッション管理やルーティング周りが勉強になりました。
データベースにはMySQLを使っています。node.jsならばmongoDBというイメージが強いですが、質問をランダムに表示する機能で、
mongoDBは現時点で正式な機能としてはランダム検索が出来なかったので、MySQLを選びました。
あと、CoffeeScriptやSCSSはJavaScriptやCSSの記法を簡単にしてくれるやつで、慣れてしまうと離れられません。
あとはTwitter Bootstrap。これなしでは生きていられません。
スマホでもなるべく早く結果ページまでたどり着けるようにしたつもりです。
オススメの動画が表示された後に、今日はこの動画の気分じゃない！と思ったときはチェンジボタンにより、同じ条件で他の動画にチェンジ！できます。
質問からやり直したいときは、さいしょから！ボタンで他の質問からやり直せます。
一刻一秒を争うエロビ探しですのでパフォーマンスには気を配りました。
最初はサーバーサイドでHTMLテンプレートを使わずに完全にREST API化して進めていましたが、
最初の表示までの若干のライムラグとSEO対策の為、最初の質問だけnode.jsでHTMLテンプレートを使用して組み立てています。
また、シンプルなサイトなのでライブラリはjQueryのみ使用し、concat/minify化はgruntのタスクとして登録しています。gzip化はNginxで行なっています。
我らがDMM様への敬意を払い、白ベース＋ポイントで赤のシンプルなデザインにしています。
・CSS（SCSS）が初めてだったので、微調整するのが大変でした。
・質問のパターンを考えるのと、紹介する動画が偏りすぎないようにするのが難しかったです。（これはまだ要調整）
・質問に対するおすすめ動画の精度をもっとあげていく。 （ユーザーの癖を把握して、機械学習とかできればいいかなと）
・おすすめ動画を表示した後に、その商品を誰かにつぶやいたり。
今回、同じ会社に勤めるエンジニア3人が約2ヶ月で作成しました。
実験的なサービスでもありますので、今後も色々と機能追加をしていくつもりです。
「外部仕様を変更しているサービスはない」という指摘が多いので追記。
てか、FacebookもTwitterも、外部仕様をもりもり変更してますよね。Facebookなんて既存の機能が無くなったことが何度もあるはずだし、TwitterもWebインタフェースを全面的にREST API経由に切り替えた当初は批判が凄かったと記憶しているけど。
結局、「うまくやるか、うまくやれないか」であって、要求の変更が仕様の変更を求めているなら、それをすることも選択肢から除外されることじゃない。
はてなブログの場合は、過去の強み（職人芸で構築されたインフラ、はてな記法、カスタマイズ性の高さ、etc）が現在の負債になっているという状況で、「じゃあ、作り直しましょう」という判断自体はそんなに間違っているとは思えない。つうか、数年ブランクが空くと痛切に感じるけど、はてな記法辛いよ、実際。もうreSTかmarkdownの拡張でいいじゃん、という感じがする。
結論としては、「はてなダイアリー2.0」を作っても誰も得しないし、不満がある人はそのままはてダ1.0を使い続ければいいじゃん、ということ。
