FuelPHPを使ってみて個人的願いとか

Qiita向けで考えていたのですが、ほぼネタなのでこちらで。

なんとかなれば嬉しいなぁ的な。

# Model

  1. "-" を含むテーブル名をそのままModelのファイル名に適用すると、階層が深くなって見にくい。

# View

  1.  値表示でエスケープを外したい場合、`View::set_safe`を使うのだけど、その値がどのように使われるかは(JavaScript?HTML?)、テンプレートPHPで決まることなので、そちらで管理するようにしてほしい。
  2. Smarty 使えばできるだろうけど、parserの設定が面倒なので、composerコマンド一発で使えるようにしてほしい。

# oilコマンド や SimpleAuthが作るテーブル

  1. 標準は、myisam ではなく、innodb が嬉しい。
  2. 標準は、テーブルの id は int型 ではなく、bigint型 が嬉しい。

# そもそもMVC

  1. scaffold(oilコマンド）っていつ使うんだろう？ベースがあればコピペで済みそう。

 

「Code for 青空文庫」とか

 

www.itmedia.co.jp

atnd.org

反響の大きさを考えると、イベント開催の判断は正解だった、ということになるのかな。

青空文庫サーバの今と今後

手弁当に期待もアリだけど、siにリプレイスの見積とかとってるのかな。会計報告みたけど、知名度の割には収益がイマイチだなぁとか、エンジニア個人より技術支援の協賛企業探したほうがよいのでは、とか。

2015/05/15 08:49

 とは書いてて、ここしか見てなかったけど、

青空文庫会計報告

収益については実際には割とまともらしい。

2013年度第4四半期会計 | 本の未来基金

 

認知のきっかけを欲しがっている中小零細SIって沢山あるから･･･、「青空文庫の技術支援してます」って、新規受注開拓時のちょっとしたアドバンテージだし、手を挙げる企業は少なくなさそう。

大企業はインフラ支援はすれど、人材を割いてくれるか否かは少し疑問。

 

ただね、基金がしっかりしているのであれば、複数SIから見積りとって、きちんとした業務としてお願いする、というのもアリだとは思うのですよ。

OSSへリソースを割くのは、業界内の相互扶助というか業界進歩や技術への先行投資というか、IT営利企業としても意味があることだけど、別業界へのボランティア活動に「社会貢献」「知名度向上」以上の意味を見出すのは、結構難しいような気がする。

 

青空文庫から恩恵を感じている人は何かを返そうと思っても不思議ではないけど、そうでない人はどこまで動機を保てるのかなぁ。

 

追記)

青空文庫へのフリーライダーを批判しているブコメがあったので以下を引用。

ただ、現状、基金への寄付は受け付けているっぽい。

青空文庫編 青空文庫のしくみ

青空文庫のトップやその他のページには、いくつかの広告が出稿されており、その収入が長年、大きな資金源となっています。青空文庫のコンテンツを利用する企業のなかには直接対価を支払いたいとおっしゃるところもありますが、青空文庫は非営利としてこれを固辞し、代わりにサイトに広告を出していただくことで、本そのものとは関わりのないところでのやりとりが成立するよう心がけています。そのため、現時点では読書の妨げになる形での広告表示は考えておりません。

 

インターンとか

実はインターンって言葉あまり好きじゃないです。


某R社を５日でクビになった話 - Code.io

 

理由。

  • 自分は研修制度の言い換えだと思ってますが、人によって極めて定義が曖昧。
  • 企業によっては単なるバイト（研修なし）もインターンと称して人を集める。
  • インターンであれば無報酬労働も問題ない、と考えている人々がいる。 

 

縁あってエンジニアインターンし、５日目にしてクビになるという出来事があり

研修生で解雇？

言い換えちゃうと「バイトの試用期間５日目でクビになった」ってことな気もするんだけど。

 

最近、「とりあえずインターンって言っておけばええやろ」的な企業も結構多いので、気をつけたほうがよい気がします。

社会人インターンシップとかもあるからね、よくわからない状態だ。

最初の３年とか

書いてみることにした。

トピック「最初の3年」について

 

  • 「最初の３年」っていうのは「仕事や社会の流れや仕組みをなんとなく理解できる期間」でよいのかな。
  • 「第２新卒カード」を切りたい場合、大体２０代半ばぐらいまで、ということを考えると、３年である程度見極める必要はありそう。
  • 仕事人生４５年として考えると、５％程度経過したことになる。野球のペナントレース１５０試合だと、最初の７、８試合でその年の優勝が決まるってこと？
    全てが決まると言い切るには仕事人生が長過ぎる。。。
  • つーか、最初の３年でその後４２年間を安定させられる程の能力の貯金するって無理っしょ。
  • ベンチャーやら個人事業主の場合、創業後３年内倒産率９０％らしいから、一つの目安にはなっているのではないかと。

そもそも積極的に新卒採用してないし、とか

就活生の人は、企業側の論理とかは気にしなくていいと思う

 「企業側の論理なんて考えなくていい」については全く同意だったりする。

就職活動に関わらず、重要な選択を行うとき、自分の都合より他人の都合を優先すべきではない。

 

ただ他に関してはどうだろうか…？

あまり首肯できない部分が多いのは、自分自身が今現在「余裕のない」企業（安定した利益を出せてない）に勤めているからだろうな、とは思う。

 

そういった会社に勤めるようになってから「貧すれば鈍する」の言葉の意味を実感するようになった。

まぁこれはしなくてもよい経験だが。

 

自分は「とっとと仕事終わらせてとっとと会社から出たい」派だからかもしれない。

CSRしかり「Pay Forward」しかりだけど、「そんな余裕あるんだったら、その分のリソースを他に回して下さい。で、自分は早く帰りたいんだけどよいですか？」と考えてしまう。 

従業員目線だと「就活生に時間を割く」というのも「無駄な会議に出席する」と同じぐらいの意味合いでしかないような。

作業量に対する労働時間のバッファが少ない場合、「就活生が話を聞きたがっているから、残業して面談してあげてよ」というのと同義だと思うのだが、それをどう考えるか。

いっその事「終業後、就活生との親睦会をします。自由参加で」としてもらったほうが気が楽だ。

 

まぁ会社の方針として「新卒採用活動を全社的にバックアップすべし」ってところもあるかもしれん。

あくまで方針なので、従業員は粛々とそれにならうだけだけど。

 

というか、「未経験者即戦力化可能」な職種ならともかく、新卒に投資して回収できる見込みが低いなら、あまり新卒採用すべきではないんだけどね。

そもそも積極的に新卒採用してないし。

テーブル定義書っていらなそうとか

だらだら読んだ。

詳細設計書という名のゴミ
詳細設計書も問題だけど、それ以上に成果物定義が問題

 

仕様書や設計書といった「資料」が必要とされるのは２点あって、

1. 開発担当者がコーディング時の指針とする為

2.開発担当者以外の人間がシステムを保守できるようにする為

 

無駄な資料が発生する原因の一つとしては、発注者側がシステムに詳しくなくて、初期開発で納品された資料を保守担当に丸投げするというスタイルなんだろうなぁ、と。

ソースコード見れば分かることを別資料でもらっても仕方ないような。

 

 

で、似たような話で、ER図ならともかく、テーブル定義書っていらなくね？とかなんとなく最近、思ったりしています。

今時のDBってフィールドにコメント付けて、スキーマー情報として併せて出力することとか割と普通にできるので。

 

 

内部設計のレビュー時に資料として必要だから作らざるを得ないとかそういう状況かなぁ。

ただ、DBからツールで自動生成できたりするので、あまり作成コストはかかってないですが。

 

mysqlだけwith句非対応とか

元々mysqlばっかで、最近よくOracle触ってるのですが。

 

Oracleでwith句の存在知って、SQLで再帰表現使えて便利だな〜、って思っていたら、

むしろwith句が使えるのが当り前っぽい。

というか、SQLiteですら使えるのね。

 

mysql “with” clause


MySQL does not support queries using the WITH syntax defined in SQL-99, also called Common Table Expressions.

This has been a feature request for MySQL since January 2006: http://bugs.mysql.com/bug.php?id=16244

Other RDBMS products that support common table expressions: