/// BANGBOO BLOG ///

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

November 16, 2009

Ora Ora Ora Ora Ora

おっすオラ忘れ易いルール、無駄無駄無駄無駄無駄無駄ッ

■DML
DB製品毎のnullの扱いを事前に調べる(word != ‘検索値'やword = nullではnullにヒットしない、is not nullを使う等)

null値はもっとも小さな値、or大きな値(nullが含まれるかnullの件数を先に確認しておく、下に例を載せた)
集計関数はNULLを無視する(下に例を載せた)

文字列は'で囲む
取得したいカラムは集計関数に使われるカラムを除いて全てGroupBy句に入れる
集計関数の条件はhaving句を使用する(where句は元のデータに対するもの)、having句には集計関数が入る(下に例を載せた)
SQLワイルドカード:複数文字%,1文字_
WINワイルドカード:複数文字*,1文字?
エスケープ文字はescape句で設定。like句の後ろにつく。escape '\'
日付と文字列の変換が必要To_char関数とTo_date関数を使用する
to_char(column,'yyyy/mm/dd hh24:mi:ss')
to_date('2009/02/21','yyyy/mm/dd')
横幅を大きくするset line 150
縦を大きくするset pages 30
unionはdistinctが掛かる、全取得はunion all
inner join onは両方のテーブルにあるものだけ、どちらかだけにあるのは無くなるイメージ
left (outer) join onは左側のテーブルにしかないものも表示、左に右の該当部をくっつけるイメージ
right (outer) join onは右側のテーブルにしかないものも表示、右に左の該当部をくっつけるイメージ
full outer join onは全ての行を表示

trancateは高速だがロールバックできない、deleteはロールバックできる、論理削除がindexメンテコスト低で良い
多対多のSQLが含まれないか確認する(下に例を載せた)

■テーブル結合4種
1対1、1対多の結合を行う
1対多でも行数が増えるが、多対多は全組合せになり行数が比例関数的に増えてしまう
多対多になるのはテーブル設計が悪いのでは?
1)inner join - on () 両方あるものを表示、欠けがでる
2)left outer join - on () どちらかは欠けがなく表示
3)right outer join - on ()  どちらかは欠けがなく表示
4)full outer join - on ()  欠けがなく表示

select URIID,NAME,UKYAKUID from URIAGE left outer join TORIHIKI
 on (URIAGE.UKYAKUID = TORIHIKI.ID)
select URIID,NAME,UKYAKUID from TORIHIKI right outer join URIAGE
 on (URIAGE.UKYAKUID = TORIHIKI.ID)
select URIID,NAME,UKYAKUID from TORIHIKI full outer join URIAGE
 on (URIAGE.UKYAKUID = TORIHIKI.ID)
select 伝票番号,行番号,処理日,商品名,担当者名,顧客名,数量 from 売上データ
 left outer join 商品マスタ on 売上データ.商品ID = 商品マスタ.商品ID
 left outer join 担当者マスタ on 売上データ.担当者ID = 担当者マスタ.担当者ID
 left outer join 顧客マスタ on 売上データ.顧客ID = 顧客マスタ.顧客ID
 order by 伝票番号,行番号

■なおjoin on句 と where句での結合の違い
1)select * from A, B where A.a = B.a and A.c = 3;
2)select * from A inner join B on A.a = B.a where A.c = 3;
両者は同じ結果、前者の方が古くからある構文,後者が新しい構文。だがOuter joinは下記にある通り違う
https://okwave.jp/qa/q8090979.html

■WHEREとJOIN ONで条件を指定した場合の違い
SELECT * FROM movies LEFT OUTER JOIN counts ON counts.movie_id = movies.id WHERE counts.date_at = '2012-12-16';
 WHERE句はJOINが終わってから評価される→Outer joinでも12/16でない映画が含まれずLEFTが欠ける
この問題の解決にはWHERE句に条件を指定するのでなくJOIN ONの追加条件として指定する
SELECT * FROM movies LEFT OUTER JOIN counts ON counts.movie_id = movies.id AND counts.date_at = '2012-12-16';
 Outer joinしLEFTの全映画が出力したいので、結合前に12/16以外のカウントを外した上で結合させると逆にLEFT側は全部でる(RIGHTの条件で絞った上でLEFT OUTER JOINだとRIGHTがNULLでもLEFTが出る)
http://hakutoitoi.hatenablog.com/entry/2012/12/17/005208

■多対多、1対多の行数
社員と職域、社員と手当、それぞれ結合しても多の行数(1x多)になる
こんな設計や操作はするなという事(多x多の行数になる、多対多の結合は行わないこと)
-- データ挿入:社員
INSERT INTO x_employee (no,name) VALUES (1, '田中');
INSERT INTO x_employee (no,name) VALUES (2, '鈴木');
INSERT INTO x_employee (no,name) VALUES (3, '佐藤');
-- データ挿入:職域(兼任が発生)
INSERT INTO x_joblevel (no,res) VALUES (1, '部長');
INSERT INTO x_joblevel (no,res) VALUES (1, '課長');
INSERT INTO x_joblevel (no,res) VALUES (2, '平');
-- データ挿入:手当(一人に幾つか付く)
INSERT INTO x_compensation (no,allow) VALUES (1, '住宅');
INSERT INTO x_compensation (no,allow) VALUES (1, '交通');
INSERT INTO x_compensation (no,allow) VALUES (2, '住宅');
-- 1対多(田中が兼任のため田中分が2行、鈴木1行で都合3行、1対多だとまだ兼任と理解ができる)
select * from x_employee
 inner join x_joblevel on x_employee.no = x_joblevel.no
-- 多対多(田中兼任2行x田中手当2行の小計4行、鈴木の1行で都合5行、田中だけで4行でるとマトリックスの意味が不明になる)
select * from x_employee
 inner join x_joblevel on x_employee.no = x_joblevel.no
 inner join x_compensation on x_employee.no = x_compensation.no

■Group by/having/where
取得したいカラムは集計関数に使われるカラムを除いて全てGroupBy句に入れるの例
select distinct boss from fun_test_data
select department, avg(salary) from fun_test_data group by department
select boss, avg(salary) from fun_test_data group by boss
select department, boss, avg(salary) from fun_test_data group by department, boss

集計関数の条件はhaving句を使用する(where句は元のデータに対するもの)、having句には集計関数が入る例
select department, count(department), avg(salary) from fun_test_data where department!="営業" group by department;
select department, count(department), avg(salary) from fun_test_data where department!="営業" group by department having avg(salary) > 45;
※moreにデータをDDLを置いておくので操作して感じる

集計関数にはsum() count() avg() stddev()標準偏差 variance()分散etc..がある

nullを無視するので、3件が100, null, 200のとき平均は150となる、nullを0にする事
SELECT AVG(NVL(SURYO,0)) AS 平均, COUNT(NVL(SURYO,0)) AS 件数 FROM TEST1

data2にnullがありカウントしようとするがnullはカウントされず1行目はダメ、件数はkeyをカウントせよ
select COUNT(DATA2) from EXAMPLE_TABLE where DATA2 is NULL
select COUNT(ID) from EXAMPLE_TABLE where DATA2 is NULL

※SQLはバグかどうか分からず失敗かどうか分かりにくい→計算式を書いてからSQLを書く
集計値の集計を行う際には集計順序に注意せよ | 実践から学ぶ分析の落とし穴 - GiXo Ltd.

■サブクエリ(副問い合わせ)
どこでもOK、any() in() some() exists() not exists()等がある、mysqlにはminus() except()はない

/// where条件が1件
SELECT 受注番号 FROM 受注表 WHERE 商品コード = (SELECT 商品コード FROM 商品表 WHERE 商品名 = 'JUICE');
/// where条件が複数
SELECT 受注番号 FROM 受注表 WHERE 商品コード IN (SELECT 商品コード FROM 商品表 WHERE 単価 = 400);
/// havingに
SELECT 顧客コード,COUNT(DISTINCT 受注番号) FROM 受注表 GROUP BY 顧客コード HAVING 受注個数 < (SELECT MIN(受注個数) FROM 受注表 WHERE 顧客コード = '002');
/// fromに
SELECT MAX(AVG_J) AS MAX_AVG FROM (SELECT AVG(受注個数) AS AVG_J FROM 受注表 GROUP BY 顧客コード) ;
/// selectに(出力表のカラム数は1個だけで、これが変わる等はできないかと)
SELECT 顧客コード,AVG(受注個数), (SELECT AVG(受注個数) FROM 受注表) FROM 受注表 GROUP BY 顧客コード;

selectサブクエリにカラムを一つづつ足せば複数も可だが
select name, res,
 (select allow from x_compensation where x_compensation.no = x_employee.no limit 0, 1),
 (select allow from x_compensation where x_compensation.no = x_employee.no limit 1, 1)
 from x_employee inner join x_joblevel on x_employee.no = x_joblevel.no inner join x_compensation on x_employee.no = x_compensation.no

/// 相関サブクエリ(出力表のカラム数が変わる等はできないかと)
メインクエリの行ごとにサブクエリを実行、結合をサブに記入している、違う書き方ができるかも知れないがサブからでなくメインから考えている感じ
例1)
SELECT * FROM 商品表 AA WHERE '20010401' IN  (SELECT 納品日 FROM 受注表 BB WHERE AA.商品コード = BB.商品コード);
例2)
SELECT SUM(受注個数),納品日 FROM 受注表 PP GROUP BY 納品日 HAVING SUM(受注個数) > (SELECT 150 + MAX(受注個数) FROM 受注表 QQ WHERE PP.納品日 = QQ.納品日);

■Union
UNION句でマージする複数のSELECT文は、(1)SELECT句のカラム数が同じこと(2)カラムのデータ型が同じか、変換可能であること
select shit from ass union all select kuso from ketsu

■SQLはカラム数の増加数で構成考える?
left outer joinはカラム数がカラム数の合計から共通のjoin onのカラム数を引いた数(行数は同じ)
 full outer join はカラム数がカラム数の合計から共通のjoin onのカラム数を引いた数(行数はleftの要素数にrightの要素数を合計したもの)
unionは重複を除外し表を足し合わせるため行数が両表の合計行数(カラム数は合致必要でカラム数は変わらない)
unian allは重複を除外せず表を足し合わせるため行数が両表の合計行数(カラム数は合致必要でカラム数は変わらない)
cross joinはカラム数が両表のカラム数の合計、行数は両表の行数の掛け算
 再帰的にSQL処理はcross joinし条件を付けるか?
  標準SQLのFrom句のカンマはcross joinとなる
with句は副問い合わせを見やすくしたもの
distinctで(組み合わせで)一意になる行のみにし重複を省く
UNION とUNION ALLの違い - Qiita
CROSS JOIN (クロス結合)を使ってデータを取得する - JOIN (結合)を使いこなそう - SQL Server 入門 (sql55.com)
SQLのDISTINCTとは?(OracleやMySQLで使用する方法) | IT職種コラム (it-kyujin.jp)

■テーブル設計、制約
CONSTRAINT pk_uriage PRIMARY KEY (伝票番号, 行番号),
CONSTRAINT fk_shohin FOREIGN KEY (商品ID) REFERENCES 商品マスタ(商品ID)
CONSTRAINT ck_gender CHECK (性別=0 OR 性別=1)
制約は列に指定しても、うしろで指定してもどちらでもよい
CONSTRAINTのキー名を省略するとオラクルが勝手につける
主キーにはNULLは入らない
ユニークキーにはNULLを入れてもよい
NOT NULLの未入力はエラー

■シーケンス
シーケンスはオブジェクトとして表とは別に作成する
デクリメントはできないので修正はDROPして作成し直す
DUALはダミー表
nextvalはインクリした後の値
currvalは現在地
create sequence testseq
select testseq.nextval from dual
select testseq.currval from dual
insert into URIAGE (URIID,URIDATE,UKYAKUID) values (testseq.nextval,'09-11-16','101')
drop sequence testseq

■ビュー
頻繁に行われるような問い合わせをスキーマに格納しておく、パフォーマンスが上がる場合がある
集約等をしなければパフォーマンスには問題がない。次を使うとパフォーマンスが落ちる。OLAP 関数(RANK, DENSE_RANK, ROW_NUMBER 等)、集約関数(AVG, COUNT, SUM, MIN, MAX)、集合演算子( UNION, INTERSECT, EXCEPT 等 )
ビューは検索だけでなく、データの追加、更新、削除も行える※使用しない方が良い?
create view 売上ビュー as
 select 伝票番号,行番号,処理日,商品名,担当者名,顧客名,数量 from 売上データ
 left outer join 商品マスタ on 売上データ.商品ID = 商品マスタ.商品ID
 left outer join 担当者マスタ on 売上データ.担当者ID = 担当者マスタ.担当者ID
 left outer join 顧客マスタ on 売上データ.顧客ID = 顧客マスタ.顧客ID
 order by 伝票番号,行番号
select * from 売上ビュー

■用語
concat()…CONCATENATE 文字連結
coalesce()…コーレス、合体する、与えられた引数のうちNULLでない最初の引数を返す
LPAD() RPAD()…文字の右詰左詰め
OLAP…OnLine Analytical Processing=分析、キューブ

■インデックス
1)インデックスが効かない
関数 where datediff(now(),mod_date)>180
式 where col1 / 2 = 0
否定構文 where col1 != 3
Like検索(前方一致除く) where col1 like '%string%'とかwhere col1 like '%string'とか
2)複合インデックスでは指定順が重要
index a
 create index idxA1 on tbl (col1);
 create index idxA2 on tbl (col2);
 -> where col1 = x > idxA1が使用される
 -> where col2 = x > idxA2が使用される
 -> where col1 = x AND col2 = x > idxA1か2のどちらかが使用される
index b
 create index idxB1 on tbl (col1, col2);
 -> where col1 = x > idxB1が使用される
 -> where col2 = x > インデックスは使用されない
 -> where col1 = x AND col2 = x > idxB1が使用される,indexA1,A2より高速
index c
 create index idxC1 on tbl (col2, col1);
 -> where col1 = x > インデックスは使用されない
 -> where col2 = x > idxC1が使用される
 -> where col1 = x AND col2 = x > idxC1が使用される,indexA1,A2より高速

■RFM(recency frequenctry monetary)
SELECT name, MAX(date), MIN(date) FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no GROUP BY name ORDER BY MAX(date) DESC
SELECT name, count(x_bill.no) FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no GROUP BY name ORDER BY count(date) DESC
SELECT name, sum(total_bill) FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no  GROUP BY name ORDER BY sum(total_bill)  DESC
SELECT name, SUM(price * unit) FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no RIGHT JOIN x_purchase ON x_bill.no = x_purchase.p_no GROUP BY name ORDER BY SUM(price * unit) DESC

SELECT name, MAX(date), count(DISTINCT x_bill.no), SUM(price * unit) FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no RIGHT JOIN x_purchase ON x_bill.no = x_purchase.p_no GROUP BY name ORDER BY SUM(price * unit) DESC
 ※購入頻度は多対多で重複が出るのでカウントはdistinct primaryKeyで重複を含めない

↓順位を点数化のため、MySQLにはRownumがなく変数を使いシンプルな表でまず作った
SET @rownum_recent=0; 
SELECT @rownum_recent:=@rownum_recent+1 as rank_recent, no, name, recent  from
 (SELECT x_employee.no, name, MAX(date) as recent FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no GROUP BY name ORDER BY MAX(date) DESC) as t1

SET @rownum_frequent=0; 
SELECT @rownum_frequent:=@rownum_frequent+1 as rank_frequent, no, name, frequent from
 (SELECT x_employee.no, name, count(x_bill.no) as frequent FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no GROUP BY name ORDER BY count(date) DESC) as t2

SET @rownum_money=0; 
SELECT @rownum_money:=@rownum_money+1 as rank_money, no, name, money from
 (SELECT x_employee.no, name, SUM(price * unit) as money FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no RIGHT JOIN x_purchase ON x_bill.no = x_purchase.p_no GROUP BY name ORDER BY SUM(price * unit) DESC) as t3

↓まとめる(user_noで結合した、別名を付ける計算カラムよりどの元の表かが重要かもLeftかRight joinかで)

SET @rownum_rank=0;
SET @rownum_recent=0;
SET @rownum_frequent=0;
SET @rownum_money=0;

SELECT @rownum_rank:=@rownum_rank+1 as rank, rank_recent+rank_frequent+rank_money as least_score_wins, t1_r.no as user_no, t1_r.name, recent, frequent, money, rank_recent, rank_frequent, rank_money
FROM (
   SELECT @rownum_recent:=@rownum_recent+1 as rank_recent, t1.no, t1.name, recent
   FROM (SELECT x_employee.no, x_employee.name, MAX(date) as recent FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no RIGHT JOIN x_purchase ON x_bill.no = x_purchase.p_no GROUP BY x_employee.no, x_employee.name ORDER BY MAX(date) DESC) as t1
) as t1_r
LEFT OUTER JOIN (
   SELECT @rownum_frequent:=@rownum_frequent+1 as rank_frequent, t2.user_no, t2.name, frequent
   FROM (SELECT x_bill.user_no, x_employee.name, count(distinct x_bill.no) as frequent FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no RIGHT JOIN x_purchase ON x_bill.no = x_purchase.p_no GROUP BY x_bill.user_no, x_employee.name ORDER BY count(distinct x_bill.no) DESC) as t2
) as t2_f
ON t1_r.no = t2_f.user_no
LEFT OUTER JOIN (
   SELECT @rownum_money:=@rownum_money+1 as rank_money, t3.no, t3.name, money
   FROM (SELECT x_employee.no, x_employee.name, SUM(price * unit) as money FROM x_employee RIGHT JOIN x_bill ON x_employee.no = x_bill.user_no RIGHT JOIN x_purchase ON x_bill.no = x_purchase.p_no GROUP BY x_employee.no, x_employee.name ORDER BY SUM(price * unit) DESC) as t3
) as t3_m
ON t2_f.user_no = t3_m.no
ORDER BY least_score_wins asc

■NULLの件数を事前に数えておく
SELECT *
 FROM (SELECT 'value', count(COALESCE(value,0))  FROM bangboo_data.x_data WHERE value IS NULL)
 union all
 (SELECT 'value2', count(COALESCE(value2,0))  FROM bangboo_data.x_data WHERE value2 IS NULL)
 union all
 (SELECT 'v_no_null', count(COALESCE(v_no_null,0))  FROM bangboo_data.x_data WHERE v_no_null IS NULL)
↑が安全策

SELECT count_null_1, count_null_2
 FROM (SELECT value, count(COALESCE(value,'')) as count_null_1 FROM x_data WHERE value IS NULL GROUP BY value) as t1,
 (SELECT value2, count(COALESCE(value2,''))  as count_null_2 FROM x_data WHERE value2 IS NULL GROUP BY value2) as t2
 ※From A, B, C でクロス結合となり全組み合わせがでる、1行ずつならOKだが、、
 ※SQLはカウント0件をグルーピングできない、表示自体存在しないことになるから、↑は少々危険で↓で
SELECT count_null_1, count_null_2
 FROM (SELECT count(COALESCE(value,'')) as count_null_1 FROM x_data WHERE value IS NULL) as t1,
 (SELECT count(COALESCE(value2,''))  as count_null_2 FROM x_data WHERE value2 IS NULL) as t2,
 (SELECT count(COALESCE(v_no_null,0))  as count_null_3 FROM x_data WHERE v_no_null IS NULL) as t3

■SQL一覧
 https://qiita.com/tatsuya4150/items/69c2c9d318e5b93e6ccd
UPDATE テーブル名 SET カラム名 = 値, カラム名 = 値  WHERE id = 1
INSERT INTO テーブル名 VALUES ('1')DELETE FROM テーブル名 WHERE 条件
intersectは重複するもの SELECT name FROM ユーザー1 INTERSECT SELECT name FROM ユーザー2
 ※unionは和集合、exceptは差集合、intersectは積集合


Posted by funa : 06:54 PM | Web | Comment (0) | Trackback (0)


November 2, 2009

Expire State of Mind

--To be expired
車免許 H24.3.xまで 1ヶ月前
船舶 H22.6.xまで 1年前から更新可能(失効しても再発行可)

--To be canceled
青山 - H22.6末までに解約
JAF 2010.3末 2010.2末までに解約

--To be applied
東京マラソン 2月   8月申し込み
大阪マラソン 11月  4月申し込み
神戸マラソン 11月  4月申し込み
京都マラソン 2月  8月申し込み
ドコモマンスリープレゼントは毎月 http://www.dcmx.jp/st/
イオンhttp://www.aeoncredit.co.jp/

■車保険
クレジット一括でないと分割は年10%位掛かる、弁護士費用特約は付ける
気になる特約:等級プロテクト
等級の引継ぎは7日以内の再契約が必要、それ以上は条件が厳しいができれば中断証明を貰う
ファミリーバイク特約は5000円固定(対人対物は車と同じ額、自損は1500万)、単独でバイク保険を掛けた方が内容が充実?等級が上がれば安くなるし

■回線を変えることでキャンペーンが適用される、NTT/au/旧USEN
 縛りが12ヶ月くらいが多い
 旧USENの回線が通っていないことが多い
 集合住宅でも契約個数が少ないと逆に高くなるケースも(特にau)
 プロバイダはどこでも良いだろ
 メールoutboundポート25番ブロックでもサブミッションポート587番を使える所
 以上の条件をクリアできるなら乗り換えろ

更新管理アプリでも作ろうかな?

Posted by funa : 05:36 PM | Column | Comment (0) | Trackback (0)


October 29, 2009

Use + Able + T
俺のを見てスムーズクリミナルだとヤコブニールセンが言ったとか

- ユーザビリティ

Posted by funa : 09:04 PM | Web | Comment (0) | Trackback (0)


October 5, 2009

Engine OH

09kx250f ■方針
1)カムだけなら=水・オイル・フライホイールそのままでOK、カムチェーン吊っておく。フライホイール(オイル)を外してやると楽だが、、
2)ピストン=水抜く、オイル抜く、フライホイール外す

■シム調整
EX 0.17-022mm、 IN 0.10mm-0.15mm
1)各タペットのクリアランスをシックネスゲージで測る
2)調整量を0.05mm単位でメモる(シム0.05mm刻みなのでそれ以上の調整が要るもののみ)
3)カム外す
4)要調整のシムをマイクロゲージで測る
5)調整量を上乗せしたシムに変更する

■事前準備
上死点は上側の切れ込み
カムのハの字、カムのポッチとチェーン位置を写真で取る(若干どちらかにずれているのでマニュアル通りには行かない、事はない)
事前にカムチェーンの弛みチェックし覚えておく

■コツ
両方のカムいっぺんにチェーンガイドを広げるようにしてチェーンを引っ張りインストール
フライホイールを外すとチェーンとチェーンガイドが正しい位置にあるか分かり易い
排気側のカムチェーンは特に張るようにしてポッチを合わせる
カムは上死点で逆ハの字になる、シックネスゲージで測ればカムのポッチが合ってるか分かる
クランクを工具で回す場合はテンショナーをつけた状態で回す
カムチェーンは毎回交換した方がいいのでは?
リングは前日に組んでおく、ヘッドガスケット、ピストンピンもね(ガスケットは冷却確認)
ヘッドの前に排気側チェーンガイドを組むこと
フライホイールなしでも上死点が分かるように目印を付けると楽
カムの位置を合わせた後、吸気側のチェーンガイドを入れてフライホイールを入れると楽
キックを蹴って引っかかりを感じたらorバルブがピストンに当たる音が出たら、カムタイミングが間違っている、カムチェーンのやり直し。写真とおりにすること

■使用工具
プーリーホルダ、フライホイールプーラー、トルクレンチ、モリブデンオイル、シックネスゲージ、マイクロゲージ、ピストンリングコンプレッサー

(写真:09KX250F/クリックで拡大)

全合成レーシングオイル(1500-2500yen/L):カストロールPower1R4Racing、モトレックスCrossPower4T、ホンダG4(G3)、ヤマルーブ4RS、ワコーズTR/4CR、モチュール300V4T、ニューテックNC51、広島高潤KZ4stRacingSpecR

Posted by funa : 08:44 PM | Gadget | Comment (0) | Trackback (0)


September 10, 2009

Re Tweet
俺の迷つぶやきをまとめる予定

物事には常に裏側に本筋がある。このアイコンを見れば分かる。
理論でもなく、感性でもない。両方だ。このアイコンを見れば分かる。
The internet is better than me.

Stay tuned!!

Posted by funa : 11:29 PM | Column | Comment (0) | Trackback (0)


July 31, 2009

Don't race to lose

法的論点+αとして心証

だけれど心証では絶対負けられない。
TVに出て相手に嘘を言わせなくする、世間の後押しなど、そこまでやるくらい大事。
素人ほど法律だけで交渉しようとするのではないか?悪い奴は知っている

心証は嘘でもどちらが本当ぽいかが重要、判断が裁判官次第だから(偽証だけど)
その為に積み上げる事、相手が嘘をついても崩せるように想定されるストーリーを練っておく事
法的論点はとりあえずグレーに持って行け

#触りだけ、、完全なフローを理解したので解禁OKのタイミングで新サイトを作ってしまおうかと

Posted by funa : 12:24 AM | Column | Comment (0) | Trackback (0)


July 22, 2009

A Rainbow Between Clouds‏
形態素解析Mecabを使いマルコフ連鎖で文章を生成してみようかと、
WinじゃなければMecab PHP拡張モジュールを使う方がいいのだろうが
 
1)MeCabのサイトからwindows版をDLしてインストール
 
2)環境変数のPathにC:\Program Files\MeCab\binを追加すると
cmdでmecabと打っただけで実行される
>mecab input.txt > out.txt
 
3)PHPのコードでは、こう。バッククォートで囲むとコマンド実行される
$output = `mecab "C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\dbcrawler\test.txt" > "C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\dbcrawler\results.txt"`;
?>
 
このタイトル使いたかっただけ、雲(クラウド)にかかる虹を探していますwww

EUCやってるやん、俺も提唱し続けry
http://itpro.nikkeibp.co.jp/article/COLUMN/20090702/333080/


///余りが出る 割り算オンリー計算機
ありそうでなかったので、作った
http://pimpub.jpn.org/divide/

Posted by funa : 08:08 PM | Web | Comment (0) | Trackback (0)


June 20, 2009

Plasticity

抵抗勢力が無料を望んでいるのか?
少しの金でコンテンツを作らせておけば、新参者が市場に入っていける余地がなくなる(クソッタレ)。経済縮小を問題視しているならWEBチャネルでの雇用を増やせばいい、報酬を適切にすればいい事なのだ。ネットは悪ではない、正当に評価されていないことが問題なのである。

WEB課金が根付く時
それ以前よりそれ以降を考えないと

#哲学じゃないよ、俺にしか記憶に残らないように分かり難く書いているだけ、ましてや主張でもない

Posted by funa : 09:41 PM | Column | Comment (0) | Trackback (0)


June 20, 2009

No sense of direction

OSSをAPIと考えたり、WEBサービス系のAPIを使ったりで
決済関係をやらなアカン、俺の中で決済が熱い、熱いだけやけど

-WEB POS OSS

ドキュメンタリー?越前屋俵太だろ、探偵ナイトスクープ、Punk'd、Boiling Pointそんなバイブが見たい
http://www.sonymusic.co.jp/etv/matsumachi/index.html

何でもほのめかしゃぁ、エエってもんでもないでwwwwwwwwww

Posted by funa : 05:34 PM | Web | Comment (0) | Trackback (0)


June 20, 2009

He said she said argument
///成果主義

企業の経営者と外資系コンサルティング会社が、合法的に給与を引き下げる理屈を探し悪用した。その役目を果たしたのが成果主義だった。これが出発点だから会社が活気づくはずがない。

-成果とは結果である
-成果は数値で表す必要がある
-評価は客観的であるべき
-評価には必ず差をつける
-成果は処遇に直結させる
このような成果主義への思い込みがあるからこうなる。

-個人プレーで職場のチームワークが悪化、部下の育成もおろそかに
-足の引っ張り合いで上司と部下の信頼関係にひびが入る
-評価される人と同じくらい頑張って成果を出しておきながら評価されない
-低い位置に甘んじている人もおり、全体に与える影響を考えて早期に対処することが必要になっている
-評価者とその取り巻きで構成されるコミュニティーに入れなかった社員の評価がどんどん悪くなる

→非金銭的報酬が割合利くのでは?
-アメリカ有名企業では社員に与える全報酬のうち、1.5%は非金銭的報酬
-特別休暇、表彰制度、感謝状、勤務内の研究制度、食事の提供、保育施設、ギフトカード等々
-金銭的報酬と非金銭的報酬が機能して、社員を生かす会社の土台となる。

///人事制度

http://business.nikkeibp.co.jp/article/manage/20090512/194224/
トヨタは一部の人が活躍し、その人だけが会社を引っ張っていくような発想を取らない会社。組織はフラット化され社員全員が持てる力を発揮し、チームとしてパワーを発揮することに主眼を置いる。目標は設定するが、目標を達成するためにどういう行動をとったのかというプロセスのみで評価しようという大胆な仕組み。成果の数字では無い。

100を目標達成と設定すると、普通、99ではダメで101作れたら1%上乗せしようという形で目標管理による評価を行うはずだが、トヨタはこういう形で目標を設定したりはしない。なぜ101は良くて99はダメなのか、言い切れる根拠がないから。

評価項目としては、課題独創性、課題遂行力、組織管理力、人材活用力、人望、専門知識

人望とは私心がない事。「12年前に彼はこういうふうに助けてくれた」「5年前にあいつは自分の部署のことばかりを考えていた」というように、過去のエピソードが人望となる。能力があるかどうかを、その能力が具体的に発揮された行動履歴で見るコンピテンシー評価を行っている。

1番と2番を高く評価して厚遇しても、誰も文句は言わない。逆に貢献度の最も低い10番目と次に低い9番目の人も明らかで、その人たちが低く評価されて処遇が良くなくても異を唱えない。問題なのは3番から8番までの中間に位置する人たちは、どんぐりの背比べなのに差をつけようとするから不満が出る。知的レベルの高い人が集まっている会社ほど、士気が下がる。

半分より下に位置づけられた人が著しくやる気をなくす一方で、半分より上とされた人のやる気はさして上がらない。つまり、評価によって無理に差をつけると、全体のやる気の総和は減少してしまう。差をつけなければならないほど大きな差でなければ、差をつけないのが良く、全員が平均点より上で、基本的にトヨタでは差をつけない。

トヨタと全く逆のリクルート、個人の業績が明確な会社は、個々の社員の短期的な結果を評価してあげることで最も納得が高まり頑張る。この職務ではこういう成果を期待すると明示する。そして、それを充足したかどうかだけで評価する。

#グローバル化には実は言語や慣習の問題は存在しない、数字のみで語ればよい?

Posted by funa : 05:21 PM | Column | Comment (0) | Trackback (0)


Navi: <  10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28  >
PhotoGallery


TWITTER
Search

Mobile
QR for cellphone  QR for smart phone
For mobile click here
For smart phone click here
Popular Page
#1Web
#2Hiace 200
#3Gadget
#4The beginning of CSSレイアウト
#5Column
#6Web font test
#7Ora Ora Ora Ora Ora
#8Wifi cam
#9みたらし団子
#10Arcade Controller
#11G Suite
#12PC SPEC 2012.8
#13Javascript
#14REMIX DTM DAW - Acid
#15RSS Radio
#16Optimost
#17通話SIM
#18Attachment
#19Summer time blues
#20Enigma
#21Git
#22Warning!! Page Expired.
#23Speaker
#24Darwinian Theory Of Evolution
#25AV首相
#26htaccess mod_rewite
#27/// BANGBOO BLOG /// From 2016-01-01 To 2016-01-31
#28竹書房
#29F☆ck CSS
#30Automobile Inspection
#31No ID
#32Win7 / Win10 Insco
#33Speaker
#34Arcade Controller
#35Agile
#36G Suite
#37Personal Information Privacy Act
#38Europe
#39Warning!! Page Expired.
#40GoogleMap Moblile
#41CSS Selectors
#42MySQL DB Database
#43Ant
#44☆od damnit
#45Teeth Teeth
#46Itinerary with a eurail pass
#47PHP Developer
#48Affiliate
#49/// BANGBOO BLOG /// From 2019-01-01 To 2019-01-31
#50/// BANGBOO BLOG /// From 2019-09-01 To 2019-09-30
#51/// BANGBOO BLOG /// On 2020-03-01
#52/// BANGBOO BLOG /// On 2020-04-01
#53Windows env tips
#54恐慌からの脱出方法
#55MARUTAI
#56A Rainbow Between Clouds‏
#57ER
#58PDF in cellphone with microSD
#59DJ
#60ICOCA
#61Departures
#62Update your home page
#63CSS Grid
#64恐慌からの脱出方法
#65ハチロクカフェ
#66/// BANGBOO BLOG /// On 2016-03-31
#67/// BANGBOO BLOG /// From 2017-02-01 To 2017-02-28
#68/// BANGBOO BLOG /// From 2019-07-01 To 2019-07-31
#69/// BANGBOO BLOG /// From 2019-10-01 To 2019-10-31
#70/// BANGBOO BLOG /// On 2020-01-21
#71Bike
#72Where Hiphop lives!!
#73The team that always wins
#74Tora Tora Tora
#75Blog Ping
#76無料ストレージ
#77jQuery - write less, do more.
#78Adobe Premire6.0 (Guru R.I.P.)
#79PC SPEC 2007.7
#80Google Sitemap
#81Information privacy & antispam law
#82Wifi security camera with solar panel & small battery
#83Hope get back to normal
#84Vice versa
#85ハイエースのメンテ
#86Camoufla
#87α7Ⅱ
#88Jack up Hiace
#89Fucking tire
#90Big D
#914 Pole Plug
#925-year-old shit
#93Emancipation Proclamation
#94Windows env tips
#95Meritocracy
#96Focus zone
#97Raspberry Pi
#98Mind Control
#99Interview
#100Branding Excellent
Category
Recent Entry
Trackback
Comment
Archive
<     December 2023     >
Sun Mon Tue Wed Thi Fri Sat
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Link