「リファレンス」を含む日記 RSS

はてなキーワード: リファレンスとは

2018-11-10

増田プログラマー養成講座 その19 SQLデータ更新

前回は、Webアプリの骨組み(スケルトン)に、SQLデータの追加と取得をやりました。

今回は、SQLデータ更新をやりましょう。

 

メッセージ更新

 

編集ページにジャンプするリンク

前回作ったメッセージ一覧に、[編集]のリンクも入れておいた。

<td><a href="welcome/update/<?php echo $item['id']; ?>">編集</a></td>

という1行の部分。

[編集]をクリックすると、編集用ページにジャンプする。

ブラウザーHTMLソースを見ると、以下のようなHTMLになってるはず。

<td><a href="welcome/update/2">編集</a></td>

これは「メッセージID番号が2」を対象にして、編集ページにジャンプすることを意味する。

 

Controllerの改造

編集用ページのコントローラーを作ろう。

「http://localhost/waf/welcome/update/2」というURL編集ページにアクセスしたら、メッセージID番号の「2」を受け取れるようにしたい。

URL文字列を処理して「2」を取り出せるようにしよう。

 

// 更新画面

public function update($id = '')

{

 echo "ID=".$id;

 $this->load->view('chat_update');

}

 

CodeIgniterでは、URLから文字列を取り出す方法がいくつか用意されている。

  1. 「update($id = '')」のようにメソッド引数「$id」を用意すれば、「2」の部分を取り出せる。
  2. 引数を使う以外の方法も用意されていて、「$id = $this->uri->segment(3);」のように書けば、「2」の部分を取り出せる。

// 更新画面

public function update()

{

 $id = $this->uri->segment(3);

 echo "<hr> ID=".$id;

 $this->load->view('chat_update');

}

 

Controllerの改造の解説

CodeIgniterで、URL文字列から特定部分の文字列を取り出す方法を見ておこう。

 

例えば、「http://localhost/waf/welcome/update/aaa/bbb/ccc」というURLアクセスしたときCodeIgniterではURL中の「aaa」「bbb」「ccc」という部分は、以下のようにして取り出せる。

$seg1 = $this->uri->segment(1); // → 1番目のURL文字列:「welcome」=コントローラークラス

$seg2 = $this->uri->segment(2); // → 2番目のURL文字列:「update」=クラスの中のメソッド

$seg3 = $this->uri->segment(3); // → 3番目のURL文字列:「aaa」の部分

$seg4 = $this->uri->segment(4); // → 4番目のURL文字列:「bbb」の部分

$seg5 = $this->uri->segment(5); // → 5番目のURL文字列:「ccc」の部分

URLを「/」で区切って、base_url(http://localhost/waf/)の次から順番に、1番目のURL文字列、2番目のURL文字列、3番目のURL文字列、…とsegment()メソッドで順番を指定すれば取得できる。

 

Modelの改造

データベースでメッセージID指定して、メッセージを取り出す機能を用意しよう。

 

ファイルに以下のメソッドを追加する。

// Read by Id

public function read_message_by_id($id = 0)

{

 $sql = "SELECT * FROM talk WHERE id = ?";

 $param = array($id);

 $query = $this->db->query($sql, $param);

 return $query->row_array();

}

 

Modelの改造の解説

SQLの「WHERE」句で、絞り込む条件を指定できる。

 

SELECT * FROM talk WHERE id = ?

「WHERE id = 2」とすれば、メッセージID番号が2のメッセージデータが「talkテーブルから取り出せる。

もし該当するデータがなければ、返されるデータは空になる。(データが返ってこない。)

 

CodeIgniterの「row_array()」は、1件分のデータ配列の形にして返すメソッドだ。

 

Viewの改造

ファイルの内容を以下のように編集する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

  <base href="<?php echo base_url(); ?>">

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>編集</h2>

  <p>メッセージを変更して「更新する」ボタンを押してください。</p>

  <form action="welcome/update" method="post" accept-charset="utf-8">

   <label>メッセージ</label>

   <?php if (isset($talk)): ?>

   <input type="text" name="message" value="<?php echo $talk['message']; ?>">

   <input type="hidden" name="id" value="<?php echo $talk['id']; ?>">

   <input type="hidden" name="action" value="update">

   <?php else: ?>

   <p>※該当するメッセージがありません。</p>

   <?php endif;?>

   <button>更新する</button>

  </form>

  <p><a href="welcome/index">戻る</a></p>

 </body>

</html>

 

Viewの改造の解説

データベースから取り出した1件分のメッセージを表示する部分を追加した。

<input type="text" name="message" value="<?php echo $talk['message']; ?>">

の「<?php echo $talk['message']; ?>」という部分だ。

これで変更したいメッセージの本文を表示できる。

 

あと、編集したメッセージWebサーバーに送信できるように、Formタグ送信ボタン(「更新する」の部分)も追加した。

このときメッセージID番号も送信できるように、

<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">

という1行も仕込んである

 

Controllerの改造

ファイルの内容を以下のように編集する。

// 更新画面

public function update($id = '')

{

 $id = $id ? $id : $this->input->post('id'); // id -> segment or post

 $action = $this->input->post('action');

 if ($action == 'update') {

  $message = $this->input->post('message');

  $this->chat_model->update_message($id, $message);

 }

 $data['talk'] = $this->chat_model->read_message_by_id($id);

 $this->load->view('chat_update', $data);

}

 

Controllerの改造の解説

メッセージID番号を指定して、データベースから取り出し、Viewに渡すデータを用意している。

$data['talk'] = $this->chat_model->read_message_by_id($id);

 

ユーザーメッセージ編集をしてWebサーバーに送信したら、データ更新する指示を出す部分も追加した。

$action = $this->input->post('action');

if ($action == 'update') {

 $message = $this->input->post('message');

 $this->chat_model->update_message($id, $message);

}

モデルにupdate_message()メソッドを用意して、$idと$messageを渡せば、該当データ更新するようにしたい。

次は、モデルでupdate_message()メソッドを用意しよう。

 

Modelの改造

ファイルの内容を以下のように編集する。

// Update

public function update_message($id = 0, $message = '')

{

 $sql = "UPDATE talk SET message = ? WHERE id = ?";

 $param = array($message, $id);

 $this->db->query($sql, $param);

 return $this->db->affected_rows();

}

 

Modelの改造の解説

SQLの「UPDATE」を使えば、指定したレコード(1件分のデータ)を更新できる。

「UPDATE talk SET message = ? WHERE id = ?」で、talkテーブルmessageid指定して更新している。

 

CodeIgniterの「affected_rows()」メソッドは、更新した行数を返す。=成功なら1行、失敗なら0行となる。

 

補足

コントローラーの「$id = $id ? $id : $this->input->post('id');」という行は、$idの受け取り方が2パターンあるので、それに対応している。

編集ページの表示で、1回目の表示と、2回目以降の表示で、$idの受け渡し方が変わっている。

  • 1回目:URLに埋め込まれID番号をupdate($id = '')の引数$idで受け取っている。($this->uri->segment(3)で受け取るのと同じ)
  • 2回目以降:Formタグで送られてきた$idを$this->input->post('id')で受け取っている。

URLに埋め込む方法上記の1回目のような方法)は、ユーザー勝手に値をいじれるので、基本的には使わない方が良い。

 

まとめ

以上で、SQLの「UPDATE」を使った、データ更新ができた。

長々と説明したが、今回の大事な点は、SQLの「UPDATE」の使い方だ。

CodeIgniterの使い方や、Webサイトの作り方(FormタグなどのHTML知識)は、オマケ程度に見ておいて欲しい。

 

次回は、データを削除するSQLDELETE」の使い方を見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベースの参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新 ←★今ここ★

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-11-04

anond:20181104145101

ざっくりした仕組みだの構造だの機能だのはだいたい一緒なんだからあとはリファレンス片手で組んでいけるようになるんだよなあ。

言語特有の開発環境とか、定番拡張セットとか、そっちのほうが言語仕様のもの以上に格差ある感じ。

2018-10-23

増田プログラマー養成講座 その10 OOP参考書

前回はオブジェクト指向プログラミングOOP)の使いどころを学ぶために、MVCフレームワークを使ってみました。(ほんの触りだけ)

今回はOOP理解を助けるための参考書を探してみましょう。

 

OOP参考書

OOPに関する有名な本はたくさんありますAmazonレビュー評価が高い本は、定番の本が多いです。

だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初意味チンプンカンプンだと思います

最初意味が分からなくても)なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます

 

オブジェクト指向でなぜつくるのか 第2版

この本は、OOP概要、基礎知識コンパクトにまとめられています

今の自分知識の過不足をチェックできます

この本を1つの目安にして、今後の学習指針を立ててみて下さい。

 

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

https://www.shuwasystem.co.jp/products/7980html/4614.html

この本は、OOPも含むプログラム設計ノウハウ原則をまとめて紹介しています

カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます

今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います

(第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。)

 

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

https://gihyo.jp/book/2016/978-4-7741-8361-9

この本は、上記2冊の内容を具体的な事例で説明しているような本です。

OOP解説本をいろいろ読んでみると、

などといった用語に出くわすと思います

これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います

サンプルコードRuby説明されていますが、何らかのOOP言語を使ったことがあれば、Ruby文法を知らなくても、だいたい意味は分かると思います

 

プログラミング入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味理解できないと思われます

しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな!」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います

 

プログラミングって難しいイメージがありますけど、習うより慣れろの精神で、とりあえず適当に触ってみるのがいいと思います

 

その他

PHPを使って、OOP基本的な仕組みを説明をしたので、PHP入門書を挙げるなら、とりあえずこの1冊。

自分にとっては分かりやす説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。

 

Java入門書文法の基礎を学んだら、次に読んでみたい本。

デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います

(なんでこういう書き方をしてるんだろ?とか、定番の書き方=パターンがいくつかあるので。)

 

グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります

リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分メンテナンスするときに苦労が減ります

 

今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります

自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります

図書館本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。

 

本のコストパフォーマンス

リファレンス文法辞書など)は、読む頻度が多ければ、買って損はしない=元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。

プログラミング専門学校かに行ったら、学費が何十万円もしますね?それを思えば本なら安いものです。)

 

プログラミング学習曲線

プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね?

プログラムサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います

でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます

学習曲線で言えば、滑らかな右肩上がり(/)ではなく、ある時グイッと変わる階段状(_l ̄)の変化に近いと思います

なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。

理解を早める補助として、上記のような参考書活用されてみて下さい。

 

まとめ

今回までで、手続言語構造プログラミングオブジェクト指向プログラミング)の基本を知りました。

次回は、問合型言語SQL)を学び、データベースを使いましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書 ←★今ここ★

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-11

スマホが高くなったのではなく日本が貧しくなった」って本当?

iPhone XSPixel 3が発表されて、どっちも高いなぁ、ヤベェなぁと僕は思うんだけど、「スマホが高くなったのではない、日本が貧しくなったのだ」という意見をよく見かける。

2011年の段階で、iPhone 4Sの64GBモデルが67,200円。一番安い16GBモデルが46,080円。

64GBモデル比較するとiPhone XS121,824円(税込)だから、7年で1.8倍高くなっている。

外国では、7年前に6万7千円を支払ったのと同じ金銭感覚12万円を出せるってこと?

労働者の平均年収が1.8倍以上になったのかな?

金持ちの国がうらやましいね

っていう結論を書くために、過去iPhoneGoogleスマートフォン価格を調べてみた。

過去どれだけ安いかが知りたかっただけなので、全部は調べていない。

iPhone

iPhone XS Simフリー版(税込)

64GB 121,824円

256GB 140,184円

512GB 165,024円

iPhone XS Max Simフリー版(税込)

64GB 134,784円

256GB 153,144円

512GB 177,984円

iPhone 4S (2011年 SoftBank)

16GB 46,080円

32GB 57,600円

64GB 67,200円

iPhone 5s (2013年 docomo, au, SoftBank)

16GB 70,200円~72,576円 (docomo 72,576円 au 70,200円 SoftBank 70,080円)

32GB 79,920円~82,944円 (docomo 82,944円 au 79,920円 SoftBank 80,400円)

64GB 90,720円~93,312円 (docomo 93,312au 90,720円 SoftBank 90,720円)

ストレージラインナップが違うので64GBで比較すると、

2011年 67,200円

2013年 90,720円~93,312

2018年 121,824円 (XS)

2011年にはiPhoneは安くて46,080円で手に入っていたので、最低スペックしか買わない貧乏人にとっては3倍近い価格になっており、超高く感じられる。

Googleスマートフォン

Pixel 3

64GB 95,000円

128GB 107,000円

Pixel3 XL

64GB 119,000円

128GB 131,000円

Nexus 5 (2013年)

16GB 39,800円

32GB 44,800円

Nexus 5X (2015年)

32GB 59,300円

64GB 63,400円

Nexus 6P (2015年)

32GB 74,800円

64GB 80,800円

Googleスマートフォンも、まず2013年2015年で、32GBで比較して、

2013年 32GB 44,800円 (Nexus 5)

2015年 32GB 59,300円 (Nexus 5X)

と高くなっており、2015年2018年も、64GBでの比較で、

2015年 63,400円 (Nexus 5X)

2018年 95,000円 (Pixel 3)

価格が約1.5倍になっている。

Nexus 5は軽い気持ちで買ったけど、もはや遊び半分で買うには高すぎる。

リファレンス機は遊びじゃない。

2018-10-08

anond:20181007145044

英語検索してもstackoverflowのクソ投稿がひっかかるだけじゃねえか。

英語公式リファレンスに当たるなら別だが、

それは「日本語検索結果を排除する設定にせざるを得なくなってる」というの

とは関係無い話になってくるよね?

2018-09-24

anond:20180924210038

ちょっと化粧をしただけのリファレンス端末だから、結局のところ一般人が買うもんじゃないんだと思う

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だろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

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

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

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

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

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

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

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

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

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

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

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

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

私的結論

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

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

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

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

長いkeyを設定すれば不要

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

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

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

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

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

2018-08-19

作りたいものができた

IT業界SIer下請けで働いている。

土日祝日なしのシフト制だが22時帰宅毎日技術に対する興味が薄れて労働マシーン化していた。



そんな時に Leaflet という面白そうなモノを見つけたWeb地図のためのJavaScriptライブラリらしい。

学生の頃にちょこちょこ記録していた美味しいお店リストや忙しくなる前に遊んでたMMOデータを元にそのライブラリを使ってwebコテンツを作りたくなった。

15年ぶりに「とほほのJavaScriptリファレンス」を見た、今はさっと読んでいる段階だ、IT業界SIer下請け事務処理や保守や問い合わせの対応マシーン化していた

自分にはプログラミング言語を触れたのは15年ぶりだった・・・まったくわからないが読んでいて楽しい

この感覚学生の頃によくあったが社会に出たらいつの間にか忘れて早く帰ることしか頭になかった。

有給休日での代休は取ると元請けからまれ最悪、自分を含めた現場技術者を外すして別の技術者に入れ替えるよう命じられるため休むことができなかったが久しぶりに取った土日の連休

Leaflet と言うものを見てwebコテンツを作りたいなーと思ったときに頭の中で誰かが「もっと休もう、休んで自分のやりたいことを伸ばす時間を作ろう」という言葉自分に掛けた。

休まないのは経営者ぐらいでいい労働者はもっと休むべきだ、今日休日は終わり明日から忙しい日がまた始まる。



でも、これから自分時間重視で働こうと思った。

Leaflet と言うJavaScriptライブラリを使って作りたいものが出来たのだから、きっとこれは何かのチャンスに違いない。

勉強法模索中だができる限り頑張ろうと思う。

2018-08-12

なぜSQLけがこの世界で未だに職人芸じみているのか

1.リファレンス無料で読めないか

標準SQL仕様書は有料である。このご時世ありえん。

たとえばC#など.NET系のリファレンスMSDNで読むことができる。

RubyだってHaskellだってScalaだって公式サイトガイドぐらい置いてある。

そもそも標準SQLサイトは有料ですら見つけるのが難しい。

2.実装ごとに仕様が違いすぎるから

OracleDB2MySQLPostgreSQLSQLite、AccessなどSQL実装されたDBMSは様々にあるが、どれを取っても仕様が違う。

皆が標準SQLに従っていてその上で適当増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。

この点でCコンパイラ多様性のようなものとはわけが違う。

根幹的に必要機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。

これと上記1とのせいで、何かググった時に特定DBMSしか解決法にならないものが大量に出てくる。

3.最適化人間任せだから

最近プログラミング言語は大抵、雑に書いたってコンパイラ適当最適化してくれる。

同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。

SQLオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。

そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、

より速い中間言語が生成されるようSQLチューニングし直さなければならない。

これでは何をやっているのかわからない。

有名なサイトでは、初心者必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、

なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。

しかもその文法、ググってもろくな解説が無かったり、特定DBMS依存してたりと使えないオチ

4.スタイルガイドがないか

上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。

エディタが単なるメモ帳しかないようなDBMSも多いから、インデント文字数さえ個々人に任される。

インデントは2文字か4文字か。SELECTで改行するかしないかカンマは列の後ろか、前か。

いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。

まり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。

困るのは初心者である

何かの解決法をググるたびに違うスタイルからどう書いていいのかわからない。

結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。

最後

だけど、そんな職人芸じみたSQL世界が私は好きです

2018-05-27

吾輩は無職である。暇だから初めてWebサービスを作ったのである

吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。

何でも薄暗いじめめした所で手斧を投げられていた事だけは記憶している。

吾輩はここで始めて増田というものを見た。

しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。

・・・

まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた

Webサービスを中々時間が取れず作るのを諦めていたのだけど、

まぁ無職になって時間も取れたので作った次第です。

自身プログラミング生業とする職業では無く、学生時代特にプログラミングついて何か

勉強をしていた訳では無かったので一から勉強になりました。

始めたのが昨年末大晦日ちょい前なので、約5ヶ月掛かり、当初想定していた期間より

かなりの時間が掛かってしまい、反省点等含めその辺の事を書けたらなと思います

■やりたい事(実装した事)

ゲームユーザー同士を繋げるマッチングサイト出会い系ではないよ。)

ログイン機能

タスクベースでのチケット管理

・簡易コメント機能

・簡易評価機能ポイント

ステータス動作変更処理

タグをつける

上記DB管理

構成を書いた方が良いと思うので

以下になります

構成

--------------------------------------------

サーバさくらVPS 2G

OS:CentOS 7.5

WebサーバNginx 1.14

WSGI:uWSGI 2.017

FW:Flask 1.0.2

RDBSQLite3 3.7.17

ORM:SQLAlchemy 1.2.7

言語Python 3.6

フロントPure JavaScriptのみ

その他ツール等:Let's Encrypt/fail2ban/等々

--------------------------------------------

上記を見て貰えれば分かるかと思いますが、最近流行りの

フロントエンド技術等は一切入ってはいないです。

ほぼ、既存ベーシックサーバーサイド側の制御のみです。(jsで非同期通信はしてます

SPAとかVueとかの言葉最近知りました。。。

ほぼ開発終わりかけに知ったので、流石に今から構成

変えるのもなと思い、取り敢えず上記です。

■選定理

まずWebサービス作るにあたり、何が必要だろうと思い

まずは開発言語だろうと、プログラミング言語の選定で

RubyPythonかで悩みました。

Rails名前を良く聞くのでRuby on Rails触ったのですが、

Railsには馴染めなかった(扱えなかった)ので

何かマイクロFWの方が良いのだろうと、Sinatraいこうか思いましたが

Railsの印象が強く残った為、Rubyは止めてPythonに移りました。

今度は初っ端からマイクロFWが良いだろうとFlaskのサンプルを試すと

比較プログラミング学者でも扱いやすく覚える事も少ないので、PythonとFlask

の組み合わせで決定。

(気軽にプログラムを書け、自分イメージしている処理や制御を素直に実現できる点が

 書いていて気持ちが良いです。まぁ分からない所も有りますが、そう思わせてくれる点

 が良いです。モチベーション的に)

NginxとuWSGIの組み合わせはFlaskで検索すると一番でてくるのでこれに決定。

SQLite3 はマイクロFWから軽めのDBでたぶん大丈夫だと思ったのでこれに決定

ORM(SQLAlchemy)も検索で一番出てくる為。

■開発概要

・まずPythonの開発環境を整えようとなり、WindowsVagrantインストールして

 仮想マシン環境構築。ゲストOSの中にPyenv等を入れPython環境構築

上記構築後に取り敢えず小さなサンプルから作ろうとなり、簡単CRUDをFlaskで行える様にしました。

 これができた時は嬉しかったです

上記が出来てから、本番の開発に移りCRUDベースにひたすら肉付けていく

ユーザー登録機能作成/ログイン機能作成/ユーザー情報表示/編集機能/チケット作成/及び編集/バリデーション

上記平行してDB機能作成実装/検索機能作成

・細かいViewの調整とスマホ用のView作成レスポンシブルでは無いので)

・本番用のさくらVPS環境構築とセキュリティ用のツール導入とLet's Encryptでhttps

上記以外の細かい調整等含め、約5ヶ月になります

■悩んだ点/反省

・悩んだのがタグ機能周りになるとどうすればよいか、かなり悩みました。

結論を言うとToxi法を使用しましたのですがここにたどり着き、理解するのに結構時間がとられました。

また、実装したらしたで、今度はそのタグ機能検索するとなると検索ワードが1つとは限らないので

クエリーを動的に生成する必要が有り、これも実装するのにかなり時間が掛かりました。

SQL文だけならば比較的すぐに検索でヒットしますが、それをSQLAlchemyでどう実現すれば良いかから

かなり時間が掛かりました。DB設計SQLAlchemyの文法に自信は無いですねぇ。。

・1次情報リファレンスから情報得ることがほとんど出来ず(たまにはできたが)、

他人咀嚼した情報からしか情報を得る事ができなかった。

(恥ずかしながら、咀嚼されなければ理解がおぼつかない状態

Stack OverflowQiita個人ブログが無ければこのサイトできなかったので

自信の咀嚼力強化が必須だと思いました。

作成結構時間が掛かったのでもっと短くしたい

総評

・5ヶ月と時間が掛かりまた反省点も多々有るが、とりあえずサービス公開まで

もっていけた事が嬉しいです。ただただ嬉しい。

・FlaskとSQLAlchemyの情報日本語が少ないので公式リファレンスとStack Overflow

行ったり来たりしたおかげで英語アレルギーがそこまで無くなった。

成果物

・で、作った成果物は以下になります

https://gamesanka.com/

ゲームサンカと言います

オンラインゲーマー向け(e-sports)のマッチングサイトになります

名前安直小学生が5秒で考えたような名前ですが、安直で気に入っています

作った理由は、僕はBF1が好きなのでオペレーションキャンペーンと言うモード

やろうとしたのですが、時間帯が悪いのか過疎なか分からないが全然マッチングしないのですよ。

やりたいのにマッチングしないので出来ないどうしよう、と。

また、昔セールFarCry3をかなり昔に購入した時(既に4が発売済み)にCO-OPモード全然マッチしない事が有り

旬が過ぎたオンラインゲームは中々マッチしなくてほぼシングルモードしか出来ない事は割とあると思うんです。

今だとBF4もかなり人数がいない状態なので特定マップのみとか。

なのでオンラインゲームマルチプレイCo-opで人を集めたい時、PUBGやFORTNITE等バトロワゲームスクワッドを

募集する時、オンラインゲーム大会e-sports)を開きたい時に利用して貰えると嬉しいです。

主に想定ユーザーと考えているのは、FPS/TPS/RTS/MOBA等のPCゲーマーをメインに考えていますCS機やTCGでも

使って貰えると嬉しいです。

あとViewレスポンシブでは無く、PC用とスマホしかなくタブレット用の中サイズViewが無いのでご了承下さい。

タブレット解像度が高い方はPC用で見て頂ける助かります

最後にお願いがあります

僕と一緒に以下のゲームを遊んで頂ける方を募集しています

遊んでも良いよという奇特な方がいましたら当該サイト内でコメント頂けると幸いです

・BF1(PC版)

・Dead by Daylight(PC版)

それでは長々とありがとうございました。

・・・

無職はただ楽である。いな楽そのものすらも感じ得ない。

日月を切り落し、天地を粉韲して不可思議無職に入る。吾輩は死ぬ

死んでこの無職を得る。無職は死ななければ得られぬ。

南無阿弥陀仏なむあみだぶつ南無阿弥陀仏

ありがたいありがたい。

2018-04-13

カメラ質に入れたっていう先生

http://www.yomiuri.co.jp/national/20180413-OYT1T50003.html

この件ね。

http://b.hatena.ne.jp/entry/www.yomiuri.co.jp/national/20180413-OYT1T50003.html

yujilabo 年度末になると補助金の満額まで使い切らないと翌年度の補助金が減額されたりもするため、ただちに必要でない機器や薬剤を購入して保管していたりすることはよくあると思う。無駄なので仕組みのテコ入れが望まれ

timetrain 予算が無いのが最大の原因だろうな・・

mazmot どういう状況だったのかなんとなく想像がつくが、それがマズいという感覚が欠如していたのだろうか?

alt-native 売ったお金どうしたかにもよるけど、研究に充ててたとしたら、研究費不足からくる悲劇

例によってはてなブックマーク論調はこんなんなんだけど、 https://kaken.nii.ac.jp/ja/grant/KAKENHI-PROJECT-15H05528/ こちから科研費交付状況を見て頂きたい。年 500 万という予算妥当かどうかは置くとして

リファレンスシステムとしてレーザライダーに加えて、光学カメラと高精度カメラを導入した。レーダ2次元立体構造再構処理した結果と、レーザライダー光学カメラ、高精度カメラ画像処理した結果を比較評価をすることで、提案手法有効性を詳細に評価できるようになった。

お前そのカメラ買って即売っぱらっとるやんけ。ようするにこいつ研究成果においても嘘ついてるんですよ。どうにもならん、クソオブクソ。予算不足とかどうとかそういう話以前。小保方みたいなもんですよこんなん。

2018-04-08

anond:20180408113715

何の言語か知らんが、昔もそういう言語はあったぞ。

富士通製のBASICであるF-BASICは、FM-8からどんどん拡張して行った結果、FM-77AV40の頃にはリファレンスマニュアル辞書みたいになってた。

もちろん、マニュアル別売り

2018-03-28

anond:20180328160144

CSSJavaScript(もしくはjQuery)とかじゃなくてHTML

HTML5リファレンス見ながら組むのと、class名に「背景が赤だからred」とかつけなかったらそれでいいんじゃね?

2018-03-22

もー頑なな態度取るから頑なな人たちが集まってきちゃったじゃない

とりあえずリファレンス当たればネットで見えないものもわかるでしょOKねよう

2018-03-21

anond:20180321130117

リファレンスとかなくても教科書4回くらい読んだら覚えるだろ

プログラミングレベルってみんなどうやって自己評価してんの?

レベル5 : マスターレベル拡張ライブラリ記述できるだけでなく、言語の内部仕様処理系実装等についても明るい。

レベル4 : 問題なく日常的に利用できるレベル言語を使うだけでなく、その言語ライブラリを作ったり、フレームワークを作ることもできる。

レベル3 : リファレンスがなくても任意の処理が記述できるレベル

レベル2 : リファレンス本があれば利用できるレベル

レベル1 : 授業などで触れたことがある程度。日常的に利用できるわけではない。

問題なく日常的に利用できるけどリファレンス禁止は無理な私はレベル2なの?

というかどんなコードを書く前提なの?

競技プログラミング解くならリファレンスは要らんけどGUI絡んだりWEBとかだと絶対無理だけど?

スレッドとか普段使わないからどの言語でも調べないと無理ですけど?


そもそもこの判定基準考えたの誰だよ

コピペされすぎだろ

anond:20180320141834

俺もこれかな。ただし電子書籍かどうかにはこだわらない立場

書籍ネット情報ということで対比するけど、

ネット情報は最新の情報が手に入りやすかったり、

単一質問に対するピンポイントの答とかは見つかりやすいけど

断片化された情報が多く体系化されたものが少ない。

公式HPではそこで書いたことが全て公式発言になってしまうことから

「こうやって作るべき」といった公式の中でも意見が分かれる議論には言及できず、

どうしても事実だけを淡々とまとめるリファレンスのような内容に偏ったりと、

正確だけど入門や勉強には非効率ものになりがち。

(どちらかというと公式より同じ利用側の立場から教えてもらえる書籍の方が入りやすい)

それ以外のネットの誰が書いてるかわからない無料情報は間違ってる場合も多い。

ネットの仕組み上、正確な情報より、読み手面白いと思ったもの

話題になるような仕組みだから当然なんだけど。

Stack Overflow レベルになると間違いは少ないとは思うけど、

日本Qiita とかで話題になってる技術記事はひどい内容のをよく見かけるね。

反論してる人が少ないのは読み手が間違いに気づいてないのか、批判は失礼だと思ってるのか)

一方、書籍はその分野である程度評価されている人しか出版の話にならないので

最低限の内容の正確性は保証されていたり、

そもそも金を取るので読みやすさとかに配慮されていることが多い。

また書籍一冊分の分量からしても技術全体像が体系化されて説明されるので

一気にある技術全体像を掴むのには便利。

まぁ、最新情報が手に入りにくかったり、読者の最大公約数を取るので

高度やマニアックな内容に触れにくかったりという側面はあるね。

要は、それぞれ一長一短あるんだから、賢く使い分けるのがよいと思う。

からしたら、両方のいいとこ取りをすればいいのに、

IT 業界っていう理由だけで片一方の可能性を潰す理由がよくわからない。

2018-03-20

勉強スタイル

つのカードしか持っていない人は、複数カードを持っている人と比べて、切り札が少ない。

勉強にも、いろんなスタイルがある。

TPOに合わせて、最適な方法選択できると効率が良い。

 

本のメリット

知識コレクションとして、本という形態は便利だ。

いくら電子書籍が発達しても、紙の本はなくならないだろう。

あ、でもこれぐらいしかメリットいかwww

 

本のデメリット

 

もちろんWebページも参考にするよね?

本代はケチらない方が良い。必要だと思ったら買って手元に置いておく。リファレンス辞典の類は本だと便利だよね。

 

2018-02-28

せんぱいぷろぐらまーのおにいさまへ

おにいさまは言語文法を全部記憶しているの?

おにいさまは知らないことがあったとき英語公式リファレンスを調べているの?

おにいさまは英語論文を読んで情報収集しているの?グーグルスカラーを愛用しているの?

おにいさまは古典や名著といわれる本は読んでいるの?コードコンプリートは何周もしているの?

おにいさまはテスト最初に書いてるの?

おにいさまはコードを読みやすくするためにリファクタリングを完全にしているの?

おにいさまは要件定義も詳細設計も基本設計デザイン実装テスト保守もできるの?深夜も対応しているの?

おにいさまはセキュリティ対策も万全なの?xssもddosもへっちゃらなの?

おにいさまは手取り15万円なの?

おにいさま、すごい!

2018-02-16

#魔女集会で会いましょう から見るはてな村周辺の老害

最近Twitter創作界隈で #魔女集会で会いましょう というタグ流行している。やたら流れてくるのでTL上で一度や二度はタグを見たことがある方もいるだろう。

これら#魔女集会で会いましょう タグの付いた作品は、Twitter上で1作品概ね1〜4枚の画像としてアップロードされている。大まかなストーリーは、どの絵師が描いたかに関わらず「魔女人間男の子を拾い、育てる。時は流れ、育った男の子魔女ナイト的な役割を担う」という感じである

もちろん異なる絵師が各々作品を作っているのだから多少の違いはあるが、大体そんなところである

これらの作品に対して、わかり手(@anbakurakoya)氏が非常に痛快な批判をしていたのでまずは紹介したい。毒親に育てられた身としては、「ああ、わかり手さんは毒親母親側)問題について理解があるんだな」ということがよく伝わってくる。しかし、わかり手氏の批判ツイッター界隈の老害化の象徴であるかのようにも見える(これについては後述)

まずはわかり手氏の良さを伝えることからはじめよう

魔女集会タグからダダ漏れてる「彼氏みたいな息子が欲しい♡」という欲望、それリアルでやると毒親まっしぐらコースなんでマジで気をつけてな…。

小学生くらいの幼女レイプしてぇ!というキモオタ欲望と同程度には醜悪欲望である自覚をな、できればな…

自分キモさを認識し、その上で「好き」を貫けや

彼氏みたいな息子が欲しい」という願望を持つ母親毒親一種)が一部にいて、とんでもないことになっているのは経験上よく分かる。また、毒親自分キモさについて自覚的でないというのも共感できる。

さらに、下記のように「リアル創作区別しろ」と仰っているのも非常に納得が行く。

自己擁護の事例としてはこういうのね。いやその関係性が「幸せ」じゃねぇだろ、リアルでやったら毒親まっしぐらだろって話をしてるんだけど、どうも「虚構現実区別」とか言いつつ全く区別がついてないっぽくて怖いんだよね。

リアル創作というのは別のものであり、明確に区別を付けるべきだという意見は全くその通りだと思う。

で、ここで立ち止まって考えてみよう、 #魔女集会で会いましょう タグとはそもそも一体なんなのか??#魔女集会で会いましょう タグを叩いたり援護したりしている人は当然趣旨をある程度は理解していると推測されるが、念の為確認してみよう。

このタグは九頭さん@coneshait という方が最初に始めたタグで、元ツイは以下のようである

https://matome.naver.jp/odai/2151839444121733201

#魔女集会で会いましょう このタグで、『魔女が拾った男の子が成長して、魔女よりでかくなって(ごつくてむさくてがっしりしてて)魔女を全力で愛して守る男になる話』の絵を描きますので、誰か描きたい方いらっしゃればこのタグつけて好き勝手に…

魔女集会検索やすいようにと思って付けてみたやつで、企画とかではないので、みんなも気軽に描いてね~

ただやってはいけないのは誹謗中傷のみ。


ここに絵師が集まって、沢山の作品投稿された模様である。2日後や3日後の「どんな設定盛っても構わん」という追加の発言もあるものの、多くの創作が1レス目のお題に沿った『魔女が拾った男の子が成長して、魔女よりでかくなって(ごつくてむさくてがっしりしてて)魔女を全力で愛して守る男になる話』というリファレンスに沿った内容となっているようである

なぜこういったタグ流行るのかと考えると、絵師が「お題」に餓えているか流行に乗っておいて自分の絵を少しでも見てほしいと思うからなのではないか

絵を描く力と、ストーリー考える力というのは全く別物である。一枚絵の画力はあるがストーリーあんまり思いつかないというような絵師がこういったタグに飛びつくのも合理的だと思う。魔女青年を絵にしたら映えそうだし。

ではここでわかり手氏の発言の話に戻ると、 #魔女集会で会いましょう タグに群がっている人に「毒親願望」があるのだろうか?これはTwitter上の流れを見た私の推測だが、タグに群がる人々の多くは毒親願望を持っておらず、「魔女とかショタかのかっこいい絵を描いたり見たりしたかった」という程度の意思しかなかったのだと思う。

ここでもう一度わかり手(@anbakurakoya)氏のツイート引用する。

魔女集会タグからダダ漏れてる「彼氏みたいな息子が欲しい♡」という欲望、それリアルでやると毒親まっしぐらコースなんでマジで気をつけてな…。


果たして、「魔女集会タグからダダ漏れてる「彼氏みたいな息子が欲しい♡」という欲望」なんてあったんだろうか?お題なんて記号にすぎず、毒親願望なんて多くの人が持ちあわせていなかったところにわかり手氏が「彼氏みたいな息子が欲しい♡という欲望」なるありもしない概念をいきなり持ち込んでしまったのではないかと私は考察する。

同時に、わかり手氏のこのツイートについても的外れであると思う

1人でもいいから、2コマ目で子供を自立させ精神的肉体的に別れる魔女がいて欲しかった。そういう思いがある。


私がこのツイート的外れであると思う理由は「ストーリーを考える手間を極力省き、決まったお題で絵を描く遊び」をしているところに「ストーリー考えろ!」と言うのは、ナンセンスからである

毒親についてであっても、そうでないことであっても、自分意見を貫き通せるのは素晴らしいことである。また、経験則から色々なことを語るのは、後の世代にとって有益となる可能性が大いにある。

だがしかし考えてほしい。刑事モノのドラマを見て雑な気持ちで楽しんでいるときに「本物の刑事はこんなんではなくてだな...これは、現実に全く則していなくて...」とやたら絡んでくるオッサンがいたら「老害キモっ」と思わないだろうか?

わかり手氏はまさにその老害の絡み方をしていないだろうか?

Twitter特性上、TLに流れてくるのは基本的にはフォローしている人達意見であるしかフォローしている人の意見なんて小さな部分集合に過ぎない。フォロー外にはフォロー外の世界があり、当然自分より若い人達だっているし、そこにはそこの掟がある。

Twitterはてな同窓会老人村界隈でゴチャゴチャ言い合ってるのも結構なことだが、所詮老害化しつつある村であることをそろそろみんな自覚してはどうか。

2018-02-14

ポートフォリオではなく

日常利用しているリファレンスにしておくべきだったなー

後悔先立たず...

2018-02-12

anond:20180212144516

実際に教える側としてそういうケースに遭遇した。

自分は人には割としっかり教えるようにしてる。

それまでは「面倒くさい奴、変な奴、あからさまにバランスの悪い奴」を教えてきたので「何とかなるだろう」と少し考えていた。

でも、そのケースでは自分限界、思い上がりを痛感した。


相手の人の尊厳問題もあるので、具体的な話はぼかして書くけど、当方技術職。

業界としては結構 歳がいっていた人が入ってきた。

採用としては「アシスタント業務のようなもので、高度に独創性必要部門ではないので、基礎的な技術がこなせればOK。真面目な人格重要」という判断だったらしい。

しかし、その「基礎的な技術」がまるっきり出来なかった。

ネット検索すれば、「初歩の初歩」としてリファレンスが山ほどでてくるような技術

その道が好きなら、高校生でも知っているようなやり方を知らない。

「これ、仕事時間内に教えなきゃダメレベル技術かな」と思いつつ教えたが、1つ技術を覚えるのに、早い人なら2日、普通なら1週間で出来るものが、その人は1ヶ月かけても出来ない。

本人も出来なすぎて固まってしまい、タイムアップで諦める。


周りの仲間も代わる代わる教えたが、みんなサジを投げるレベルの物覚えの悪さ。

パワハラ的な教え方はしていない、むしろ子供に教えてるんじゃないかというレベルの丁寧さでも。


どうしようもなくなって、本当になにも技術必要ない単調な作業をなんとか探してきて、仕事としてはそれだけやってもらう合間に、練習をしてもらっていた。

評価はかなり困ったが、「仕事にあたる態度は真面目(あからさまなやる気のなさや態度の悪さを見せない)」という点を本人に伝えて、

しか技術の上積みはどうしても必要なので、その態度で焦らず頑張って欲しい」と伝えた。


でもその人は辞めた。

自分がこの職場活躍できる場所がないことが分かってしまったようだった。


活躍の場がない所にいつまでもダラダラいさせても、その人の時間無駄にする。

あの時を思うと、その人を「バッサリ切る」と言う判断が出来なかった自分は甘かったのではないか、と考えてしまう。

2017-11-29

何者にもなれなかった

フロントエンドエンジニアにもデザイナーにもなれなかった。


HTML/CSSリファレンスなしで書けるし、WAI-ARIAを用いたアクセシブルなコーディングもできる。

CSS設計意識して保守性を大切にしたコードを書いているし、CSSアニメーションインタラクション操作できる。

SVGを一から書く方法やいくつものブレイクポイントを持ったページのコーディングスキルも身につけた。

Gitバージョン管理をしたり、モジュールバンドラータスクランナーscssコンパイルリントを通したりする能力も得た。

インプットが大好きで、毎日毎日様々なWebに関する知識を頭に詰め込んだ。


だけどJavaScriptは書けない。

JQueryコピペして簡単DOM操作を行うのが限界だった。


然しながら、昨今のフロントエンドエンジニアJavaScriptが書けて当たり前だし。

JSフレームワークWeb AssemblyWeb Componentsを使いこなして開発している。


サーバーサイドレンダリングが主流のこの時代、生のHTMLを書いているような人種は淘汰され、

数年後には食いつなぐことが厳しくなる未来しか見えない。

両者の間には旧石器時代現代程の格差を感じる。


デザイナーなら道はあるかと思い、UIデザインにも挑戦した。

バーティカルリズムや余白設計、配色理論意識した整ったレイアウトXDIllustratorで作れるようになった。

でも「整った・整然としたレイアウト」は作れても、その先に進むことはできなかった。


全ては自分怠惰性が招いた結果である

だけど、藻掻き続けても道が拓けない。

もうこの先、どのように歩み進めればいいのかもわからない。


助けて欲しい。

何者にもなれない自分は嫌だ。

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