  |
はてなキーワード: コーディングとは
そんなに金取ってるのか。
末端でデザインとかコーディングとか（デザイン側担当）やってるけどページ数とか難易度があっても総額で50万以上もらったことないな。
って来て、その他のページも全部PCデザインとスマホデザインでそれぞれ料金設定されてるんだけど、フレキシブルデザインとかリキッドデザインってまだ主流じゃないの？
それともいちいちこっちから“昨今のトレンド”を盛り込めって指示しないとダメなの？中小企業の素人だと思ってなめられてる？
--------
って今よく見たらデザイン料のみだった。コーディング料は別だ…。
CMSはお客様お問い合わせフォームのみ。ページの更新は全部代理店に依頼が必要。
なんか大物youtuberヒカル君が、「新事業を立ち上げます」宣言しましたね。「事情があって大学いけなかったような（田舎の）高卒」と、「（都市の）企業」とをマッチングさせるってビジネス。自身の知名度を生かして高卒・高校生を集客⇒インターン・体験イベントに出席⇒採用まで持っていくことが目的で、サービス利用者の参加費はゼロ。「世の中には能力ある高卒がいるけど、彼らにはチャンスがない。だからそれを与える事業をしたい」なんてのはイケてるけど、これ人材ベンチャーにありがちの「理念だけご立派」なビジネスで終わりそうじゃね？
まさか参加者のスクリーニングをしないはずもないから、まず「優秀」な奴を選抜することになると思うんだけど、そもそも腐るほどいる高卒の中から、どうやって”能力”ある個体を見つけるの？
面接や実績、自己PRなどの評価で選別する場合、「口のうまいマイルドヤンキー」・「人当たり良さそうな美男美女」・「コード書ける引きこもり系陰キャ」の3択になるよね。高卒生の能力をこの基準で判断する場合、マッチングさせる企業は「営業ソルジャ―」「腰かけ一般職」「下級PG」が欲しい会社に限定されていくよね。
大企業の「腰かけ一般職」が都内女子大の女の子たちに浸食されていることを考えると、営業か下級PGかに絞られる。しかし、若い営業ソルジャ―を欲しがる会社は、有形・無形かかわらず粗利の低いプッシュ営業体制の場合がほとんど。下級PGを欲しがる会社だと、永遠のデバック、コーディング要員としてこき使うような委託体制がほとんど。どことは言いませんが。
そうなると、「田舎でくすぶって腐る若者」が、みごと「東京で使い潰される消耗品」に進化する。これが「高卒に夢とチャンスと可能性を与える」ってことなんですかね？ライン工とそう変わんないと思うんだけど。
かなり前時代的なボトルネックがあるし、可読性がすこぶる低い。
モジュール化を考えてない人が作っているのか、流用もしづらい。
1000行越えのコモンイベント（関数のようなもの）や、インデントの６段階ズレなんかが平気である。
初期状態＋α程度のゲームを作るだけなら良いが、凝ったものを作ろうとするほど辛くなること間違いなし。
勿論、どんなツールと比べても自分でコーディングする方が良いというのは真理ではあるのだが、WOLF RPG EDITORに関しては、「どんなゲームでも作れます」というような口コミがネット上に結構あるのが問題。
最近はDevOpsとか都合の良い単語が流行ってる所為で勘違いしてる輩が多いが、開発者と運用者は兼任させない方がいい
なぜか？運用は不意なサーバトラブル、客からの問い合わせに対応しなければならないため突発的な作業が発生する
んでこの対応を開発者に振ってしまうと、本来のコーディングに集中できなくなる
っていうやつはコード書いたこと無いやつで、コーディングしてるときに割り込まれるとマジで効率が落ちる
普通の人は意識しないかもしれないが、それほど開発は集中力を要する仕事だ
たまに並列作業が得意な人もいるが、2並列でやったら効率が50%、50%に分かれるわけではない
要するに開発者には開発に集中させ、運用者には運用に集中させる必要があるってことだ
(でもDevOpsの言いぐさじゃないが、運用者もある程度はコードの知識を持っていた方が良い)
日本型大企業の多くは、その中に構造的矛盾を抱えていることが多い。
例えば職位ピラミッドがいびつだったり、評価が建前主義だったり、ものすごく非生産的だったり。
そうしたものは、日本的な価値観で非常に大人数を組織するための必要悪かもしれない。
ところで、ソフトウェアの世界では、コーディングより重要な概念として、「構造」がある。
ソフトウェアの構造は直接眼には見えないが、要は「目的を効率よく達成する要素の成り立ち／仕組み」のことだ。
構造を考える作業は設計と呼ばれる。また、特にプロダクトの骨格となる構造はアーキテクチャといい、それを作る人をアーキテクトという。
構造、特にアーキテクチャが良くないと、そのプロダクトの構築に多大な困難が発生する。崩れた基礎の上に家を建てるようなものだ。
だから、ソフトウェア技術者の世界ではコーディングよりも構造を考えることを大切にしているし、必要とされている。
ここでタイトルに立ち返ってまとめると、次のように言える。
つまり、大企業というものは、「その組織的な構造／アーキテクチャ」に問題が多いのである。
そして、ここで仕事をする設計者／アーキテクトは、常に改善見込みのない歪な環境に身を置くことになる。
「構造」の把握・改善を得意とする人間は、歪んだ構造に居続けると精神的苦痛を受ける。優秀であれば優秀であるほど。
そうして、日本型大企業からは、優秀な設計者／アーキテクトが去って行く。
自分向け兼ねて
ちゃんと飯と睡眠を摂って運動してるか確認する。コンディション悪い状態から良い状態だと体感的に5倍くらい差がある
使ったことのない関数や書き方をするときは短いテストコードを書いて挙動を試してから書きたいコードに組み込む
長い書き方でいいから機能を実装して完成してから綺麗に書き換える。短く美しいコードよりまず自分が思いつくコードで機能を完成させる
最少の機能で作る。機能は後から足してコードが汚くなったらスクラップアンドビルドしてもよい
時間が経つと思いつくことがある。目の前ですぐに作れるものを片っ端から作って悩んだら出かけるか寝るか遊ぶかするほうが効率がいい
デバッガを使ってもバグの箇所が不明であればコードが動くところまでコードを分解してバグってる箇所を見つける
読んだコードや自分が今まで書いたコードを全てひとつのファイルに全部まとめてコーディングを開始する前に全部読み通す。最初は読む時間がかかるが読む速度は早くなるし後でマニュアルを調べてストレスもかからない
とりあえずこれくらい
後で追記するかも
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実装済みのライブラリ(サードパティ)を使うのが一番ってっとり早い
以上
=====
step1
ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps
POST /api/v1/apps
アプリ登録をわざわざコーディングする場合はライブラリとして作って提供する場合くらい（？）
(アプリを複数のインスタンスに対応させる場合はやはりコード書くしかないけど）
(登録したIDを自前サーバーで持って同一アプリで共有するとか？）
(ローカルで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
必要なパラメータ(※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
○朝食：なし
○調子
ちらほらバグが出始めたけど、どれも作ったところがミスってるんじゃなくて、仕様バグであることを偉い人たちに説明する資料を書いたりしてた。
（いやまあ別に手伝うのはいいんだけど「テストデータ作りましょうの日」があったんだからその時に言えよ、とは思った）
調子悪い日にコーディングだとかなりキツイから、テスト工程のときに気分が悪くてある意味よかったと思おう。
●3DS
なんか急にアクションの熱が高まったので、前から気になってた必殺技パネル集めのためのフィールドスマッシュを少しプレイ。
ポケモンが好きなので、ピカチュウ、リザードン、ゲッコウガ、プリンの必殺技パネルはコンプしたいかな。
そうえば、ミュウツーのDLCを買ってなかったから、それを買うかも検討したいけど、まあ今更かなあ。
最初のボスを倒すまでプレイ、ハンマーのタメ技がすごい爽快で気持ちいい。
とはいえ、毎日プレイするほどじゃないかな、あんまりアクションゲームは得意じゃないし。
気が向いたらまたプレイしよう。
このゲーム、人数と料理のできによっては、すごい勿体無い感じの進み方になるのが、すごく気にいらない。
○ポケとる
・ポケモンサファリ攻略中（残りピクシー1匹になるまで攻略、ピクシーはまだ出会えてもない）
イベントです。
ですが、以前は連勝数によってランダム報酬という超絶難易度だったため、二匹とも入手できませんでした。
ただ、今回は以前と違い、累計勝利数で確定入手できるため、久々にイベントを張り切りることにします。
まあ、時代遅れもいいところなマニュパなので、地道に頑張ります。
