はてなキーワード: 初期化とは
808 ソーゾー君 [] 2013/12/12(木) 12:35:48 ID:ZSYpe5UA Be:
通貨発行権の問題に触れると「年金もまともに運営できない日本政府に通貨発行権を?無理無理w」と政府批判をします。
原発ネタや国防ネタや年金ネタや今回の糞法案の秘密保全法案を議論すると
「日本政府は国=国民の為に機能している!日本政府=行政府を信じろ!」と言います。
このように矛盾した発言を繰り返して勝手に理論破綻してリセット=初期化=無知を演じて同じことを繰り返すのです。
http://jbbs.livedoor.jp/bbs/read.cgi/movie/10043/1378650618/l50
消えたっていうのは、デスクトップにおいてたものも、マイドキュメントに入ってたものも、ブックマークも、メールの設定も
全部完全になくなってて、初期化された状態になっていたのです。
http://bbs.kakaku.com/bbs/K0000483245/#16298563
パソコンの内蔵デバイスで、認識されない場合(されたり・されなかったりといった不安定を含めて)、
BIOS設定に「高速起動」みたいなオプションがあったら、無効にしてみると幸せになれるかもですよ。
「高速起動モード」にすると、BIOS のプログラムが、デバイスの初期化完了信号を待たないで起動処理を先にすすめたりするのでしょう。
遠隔地にいる人と連絡する、入力した文字列をコピペできるように配慮する以外の目的でメールを使いすぎる人は困る。
目の前にいるにもかかわらずメールを出して黙っているとか、あとで私連絡しましたよねというだけのためにメールを使う人はコミュニケーション障害だの可能性がある。
仕事の進行を覚えれないなからメールに記録するのは、能力を補うために仕方ないと思うが、同じ部屋にいる人には、一声かけたほうがいいと思う。
指示出しているようで指示していない。プロ野球の監督が同じベンチにいる選手にメールで指示出していたらおかしいだろ。そんな感じ。
メールを貯めすぎて、大きさが2GB越えて新しいPCに移せないとかやめてほしい。
チームで仕事しているのに退職者が出たら、そいつのメールは誰も引き継がずに初期化してしまうのだから、必要以上にメールを貯めている意味がないと思う。
そこまでサイバーに仕事をすることないだろうと思うのは、価値観の違いなんだろうか。
社外の人相手でもメールで済ます人もいれば、わざわざ電話する人もいる。
今でもあえて礼状を手紙を送る人もいる。メールの時代に手紙は目立つからね。
あと、メールのスピードが不要な人たちもいる。すぐに返事がほしいのは出した側の都合でしかない。すぐに返事がほしかったら電話を併用したほうがいい。
60過ぎたひとたちにメールやネットを教えて、10年経ってみんな70過ぎてしまった。
使う人は使っているし、使わない人はつかわない。携帯電話すら持っていない人もいる。
最近は、急に倒れたときに困るから、病院や介護の人が携帯電話を持ってと頼むみたいだ。
携帯電話を持てば、ショートメッセージが使えるからメールユーザーになるので、メールが届かない人は、携帯持っていない人くらいなんだろうな。
ネットでもメールでも連絡がつかない人のほうが希少な価値のある人になりつつあると時代に突入した。ネットにいないすごい人は簡単にたどりつけないんだよな。
JavaScriptで部分的にビューを変更したりしてると、思わぬところで要素が残っちゃってたり、消えたたりするバグがよくでるんだが、
ちょっとしたビューの変更でも、変更後のビューは一枚のユニークなビューとして定義して、レンダリングしなおしたほうがいいのかね?
もちろんHTML全部をレンダリングしなおすという話ではなく、ビューモデル?みたいな感じで保持してるビューの値を、一度全部初期化しちゃってから、
表示したい値を入れて、レンダリングする感じ。
いつもページ遷移のときは、Render○○Viewみたいなメソッドの中で、一度ビューモデルを初期化して描画したい値をビューモデルに入れる。
そして、汎用的なRenderメソッドを実行して、HTMLに描画する感じにしている。
そして部分的にビューを変えたいときは、ビューモデルの変えたいビューに対応する変数の値を変えて、Renderメソッドを実行。
この「部分的にビューを変えたいとき」に、それ独自のRender○○Viewメソッドなるものを作るべきか否か迷うときが結構あって、
初期化しても直らないってことは伝えたの?
他のキャリアがどうなっているのだろう?
アラームも鳴らないし、音が全部出ない。
ネットは問題なく使える。
1、修理対応
2,保険+で対応(お金払って交換、二回目なので8000円位)
使えないスマホにこれ以上金はかけたくないので、修理見積もりを依頼出して
代替機を借りる。
電話として使えないのに機種のローン含めて8000円位毎月請求されてるけど
電話会社が請求している。auが保険や販売も社外化しているのは責任逃れと
販売者の罪悪感を軽くするためなのかも知れない。
ショップに持っていくまでに、何回か相談にいったら「初期化したら直ります」
電話でカスタマーセンターに聞いてくれたけど、初期化の一点張り。
今回は、初期化しても直らないから持っていったのだけど、何が問題だったのか
まったくauに聞いても分からない。そんな分からないものに金を払いたくないので
他キャリアでもスマホの故障対応ってそんなもんなんでしょうか。
*補足
今回、自分で初期化しても直らないから再度ショップに行きました。
スマホのトラブル対応は、「出荷状態」しか無いのかという疑問。
※以下、言語というくくりでの話ではなくて漠然とPC用プログラム作成環境全体を指して言っていると思っていただきたい
基本的には.Netが好きだ。
Webを最初から意識して作られているし、標準ライブラリでカバーされてる範囲が広いおかげでVisual Studio入れるだけでサクサクかける処理が多いので再発明を強いられる事態に陥りにくいのが感涙ものだ。
C++/CLIもやりたいことが割とリーズナブルなコストでできるのでありがたい存在だ。
VB6は嫌いだ。
いろいろ拡張してくれた結果なのは知っているが、結局大事なところはダメ言語のままでMSから匙を投げられた存在という認識だ。
MFCも嫌いだ。
ひたすら面倒いし、出来たコードのメンテナンス性も・・・。メリットが今となっては動作の軽さだけだし(昔はむしろ逆の立ち位置だったんだろうが)。
だが、VB.Netは好きだ。
MSILを作るための道具であるがゆえに、VB6の痛い所が根こそぎ取り払われていると感じる。
C#でもいいのだろうが、セミコロンはなくても良いじゃない(あっても良いけど)。あと、オブジェクトを変数宣言しつつ初期化するとき、"クラス名 変数名 = new クラス名()"になるのが
クラス名をSystem.XXXから書いているときには耐えられない。As New万歳。
しかし悲しいかな、VB.NetはC#に押されて絶滅危惧種だ。
TypeOfを使わなくちゃいけない時にはVB.Netが恨めしく感じるけど、そんなに頻繁じゃない。
他のデメリットにしても、表記がウザくなるだけで書けない処理があるわけじゃない(このへんがVB6と決定的に違うところ)
32歳、営業職です。
プログラムとかなんもわからんちんなのですが、アプリを作りたいと思いたちアプリを
作ってみました。
とりあえず、アプリのランキングを見ていると、エロ系がやっぱり強いと思って、エロは正義!の名の下に
簡単にアプリを作るために、まずは簡単に作れるフレームワークを探す所から始まります。
フレームワークってなんですか?
それはね、なんだかわからないけど、簡単につくれるようになるものなんですよ。
詳しくは、
外人「システムを作るときに、よく利用する機能とか、構造とか、予めあると便利だろ?
俺が作っといてやったよHAHAHAHAHA」
っていう感じのものだそうです。
プログラミングなんてわからんちんだけど、HTMLくらいは作れるよ!
そんなあなたにPhoneGap(http://phonegap.com/)ということで、
とりあえずPhoneGapを使って見ることに。
でも、実際使ってサンプルを作ったりしてみると、動くは動くんだけど、
色々やろうとすると、Web上にあるドキュメントが古いのか、PhoneGapが最近になって
突如バージョンがあがったせいか、書いてる通りにやってみてもできない。
とりあえずiPhone Developer登録は既に完了していたので、Xcodeをつかってやるぜ!
俺は赤の扉を選ぶぜ!と思ったがはてさてどうすりゃいいのか。
HTMLをプロジェクトに追加するのはドラッグ&ドロップすれば完了だ。
その際にダイアログが出てくるので、"Create folder references for any added folders" を選択しておくと
元々のフォルダ構造とかが失われずそのまま追加できるのでいいぞ。
ほんでもって、UIViewControllerというのを作成する。
IBOutlet で UIWebView を利用するためのオブジェクト変数を用意しておいて、InterfaceBuilderから接続をする。
Files's Owner とかを右クリックして出てきた変数名と画面上についかしたUIWebViewをマウスでつなぎあわせれば
接続できるぞ。なんて簡単なんだ。
一番最初に行われる初期化の処理は viewDidLoad にでも書いておけばいいらしいのでここに書く。
UIWebViewはURLの書式になっていないと開けないようなので、それを調べることから始まる。
アプリ内に追加したリソースファイルは、アプリのデータに内皮されるらしい。
アプリが展開されるフォルダというのは、デバイスにより様々なのだが、そこから内皮されている
ファイルを取得するための処理というのがあるのでそれを利用する。
NSString *html_path = [[NSBundle mainBundle] pathForResource:@"index" ofType:@"html" inDirectory@"web"];
これでwebフォルダ内にあるindex.htmlファイルの絶対パスを教えてくれるというわけだ。
あとはこれを読みこませればOK。
[web loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:html_path]]];
NSURL というのがURL書式を記述するためのオブジェクトだと思っていただきたい。
ここではローカルファイルのパスを拾うため、 fileURLWithPath とするのがポイントだ。
file://nantarakantara/index.html みたいな書式になるんでしょうね。
なんだか色々理由はあるみたいなんですが、そうですかだめですか。
善は急げで、AndroidSDKとEclipseというものをダウンロード。
昔は色々設定が必要だったが、いまは開けば即使えるようになったらしい。便利便利。
こっちの場合も同じようなやつがあるんでしょう、ほらったWebViewこれを使えばいいらしい。
XCodeのときは、いかにもアプリの画面を作れば完成って感じだったけど、Androidの場合は
Layoutファイルというのを使わないといけないみたい。なんかこれはHTMLみたいな記法だな。。
どうなってんだかよくわかんないですけど、Layoutを作成して、WebViewを配置、
Androidの場合は、assetフォルダというのをつくってあげて、そこにHTMLファイルを
置けばいいらしいですよ。なるほどね。
WebViewでの開き方は、assetフォルダを直接開けばいいだけらしい。いえーい!
layoutに配置したWebViewをオブジェクト変数に呼び出して、、、
webView.loadUrl("file:///android_asset/web/index.html");
ひらいたーおっけーーーーーーー。
だけども、リンクを開くとブラウザが開いてしまうなあ。どうすればいいのこれは。
調べてみるとこうすればいいらしい。
webView.setWebViewClient(new WebViewClient(){
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
return false;
}
});
これで無事、WebView内で画面遷移するようになりました。
やっほー
そんで、なんとかつくりあげて、申請・・・
とかないんですね、公開したら公開されましたw
ていう感じで始めてつくってみたんで
よかったらダウンロードしてみて下さい!
https://play.google.com/store/apps/details?id=ff.appgroup.app001_hrenai
先日、アダルト専用ブックマーク「秘ブ」(http://hibu.jp/)を公開した者です。
http://anond.hatelabo.jp/20130308124428
これね。
http://anond.hatelabo.jp/20130308140354
の方のご指摘で「ボスが来た!」機能が欲しいということでしたので、作ってみました。
javascriptでほぼ全部実装したのですが、だいぶ苦労しました。
javascript特有の、関数をオブジェクトに登録できるとことか、できるだけ汎用的にコードを構成するとことかが難しく…。ちょっとした変態言語だとは聞いていましたけどね。
職業プログラマの方からみればそれはそれはスパゲッティな感じでしょうが、お勉強を兼ねてソースも公開したいと思います。
デフォルトでは、右下に「ボスが来た!」ボタンを表示して、クリックすると「年号→西暦変換表」の表示に切り替えます。タイトルとファビコンも変更します。
デモページ無いんで、どんな感じになってるかはhttp://hibu.jpを御覧ください。
プログラムを公開するときにはライセンスってものを設定しなければいけないらしいと聞き、一応書いておくか―と思って調べました。
結果、↓で一番上にあったGPLライセンスにすることにしました。
http://smkn.xsrv.jp/blog/2009/03/summary_for_gpl_mit_cc_etc/
http://kojika17.com/2011/01/web-designers-have-to-remember-license-summary.html
匿名ダイアリーではHTMLの部分と日本語がちゃんと表示できないみたいなので、見たい方は↓のURLで見れると思います。
http://hibu.jp/js/BossComes.js
最初、bodyタグの直下にscriptタグで読み込んでたんですが、ページ全体の読み込みが遅くなっちゃいまして。
bodyタグを閉じる直前にscriptタグで読み込むと良い感じです。
↑のkebo987654さんの回答からコードをお借りして解決。
Javascriptでタイトル名称を変更する
Favicon の動的変更の裏側
http://webcraft.seesaa.net/article/184698281.html
DYNAMIC FAVICONS
ファビコンは、一回linkタグのファビコン指定の部分を消してから、書きなおさなきゃ変わらないみたいです。
ファビコンファイルの拡張子ごとにmine-typeを変更するところは頑張った。
って具合に。
でも、関数をelementのonclickに登録するのがなかなかうまく行かなくて。
でもググった結果、↓のようにしたらできました。
動的にonclickを追加する
http://b.hatena.ne.jp/entry/http://www.jp.playstation.com/info/support/nr_20121222_ps.html
これは、初期型の中には基盤の半田が劣化(と呼んでいいのか知らんけど)して剥離してしまうケースがあって、一時的に起動させるために外部から無理やり熱風を送り込んで半田を熱膨張、接触、通電させる(そして起動しているうちに内部のデータをバックアップする)ノウハウが一部知られていることによるものと思われる。俗に言う「YLOD(Yellow LED of Death)」。
ちなみに、XBOX360にも類似の故障が多発しており、排気口をタオルで塞いで内部の温度を強制的に上昇させるノウハウが存在する。
「rrod タオル」などでググると実践しているブログなどが多数ヒットする。
HDDを抜き取って修理に出せばよいだけ。というか修理に出すときはHDDを抜き取れと説明書に書いてある。入れっぱなしで出したら強制的に初期化される。
この手の修理は丸ごと基盤が交換されるだけという場合が大半だが、初回起動時にディスクの認証を求められるのでOKを選べばすぐに使えるはず。
どちらにしても、超精密機械の塊に排気口から熱風を送り込むのは本体の寿命を縮める行為であり、メーカーが想定している状況ではない。
不測の事故の原因となりかねないので注意を呼びかけているのだろう。
「みんなの役に立つサイトを作って、一発大きく儲けたい!」と、
思い続けて、早10年(泣)。。
とりあえず、エロサイトを作るのってすごく勉強なる?楽しい?らしいので、
誰にも利用されない「へぼツール」作るより必ず誰かの為になるなぁと考え、
できるだけ、誰でもわかるように、詳細を書いていますので、
これを見るだけで、ノンプログラマーの方でも、
※記事は毎日10件更新予定です。つまり毎日このサイトだけ見に行けば困らないってことです。
http://anond.hatelabo.jp/20101219185436
http://anond.hatelabo.jp/20101203150748
http://d.hatena.ne.jp/inouetakuya/20120331/1333192327
http://anond.hatelabo.jp/20120318122617
http://anond.hatelabo.jp/20120914214121
http://anond.hatelabo.jp/20110804021353
http://anond.hatelabo.jp/20120926165533
saasesのVPS OsukiniサーバーLT メモリ512MB 月450円! アダルトOK
CentOS 64bitを選択。(メモリを食うだけなので、特に用がなければ、32bitにしよう!)
※どこにも書いてないけど、2週間以内なら取り消しできます。
☆契約時、webmin&mysqlの選択は必須にしておいたほうがいいです。私は間違えて、webmin無しにしてしまった。。
後から、再インストール(初期化)すれば、再選択することができるようです。。
申し込み後、たったの30分で接続できるようになりました。
をバリュードメインで取得。280円!安い。
/sbin/chkconfig auditd off
/sbin/chkconfig autofs off
/sbin/chkconfig avahi-daemon off
/sbin/chkconfig firstboot off
/sbin/chkconfig kudzu off
/sbin/chkconfig lvm2-monitor off
/sbin/chkconfig mcstrans off
/sbin/chkconfig mdmonitor off
/sbin/chkconfig messagebus off
/sbin/chkconfig netfs off
/sbin/chkconfig nfslock off
/sbin/chkconfig portmap off
/sbin/chkconfig rawdevices off
/sbin/chkconfig restorecond off
/sbin/chkconfig smartd off
/sbin/chkconfig xfs off
※190MBが150MBぐらいになります。
http://support.saases.jp/index.php?action=artikel&cat=63&id=312&artlang=ja
# vi /etc/httpd/conf/httpd.conf
NameVirtualHost *:80 ←これを探して、コメントアウトを削除。その下に以下を設定。
DocumentRoot "/home/ユーザーID/iphone-xvideos.info"
ServerName iphone-xvideos.info
<Directory "/home/ユーザーID/iphone-xvideos.info">
order deny,allow
Options FollowSymLinks
# /etc/rc.d/init.d/httpd restart
「httpd: Could not reliably determine the server's fully qualified domain name, using...」
その時はこちらで解決⇒http://d.hatena.ne.jp/uriyuri/20100511/1273575287
で、このままだとIPアドレスでもアクセスできてしまうので、以下もやっておく。
http://fedorasrv.com/memo/log/29.shtml
mkdir /home/ユーザーID/iphone-xvideos.info
chown ユーザーID /home/ユーザーID/iphone-xvideos.info
/home/ユーザーID/以下はpermission errorとなりアクセスできないので、権限を変える。←いいのかな?
http://blog.verygoodtown.com/2010/02/centos-apc-install-how-to/
↑これを実行した際に、「error: expected specifier-qualifier-list before 'pcre'」なんちゃらっていうエラーがでたので、以下を実行。
再度実行して、無事インストールできた。
【APCの設定】
extension=apc.so
[APC]
apc.enabled = 1
/ ←検索
n ←次の検索文字へ
]] ←最後尾に移動
:q! ←保存せずに終了
--------------------------
# /etc/rc.d/init.d/httpd restart
vi /home/ユーザーID/iphone-xvideos.info/index.php
phpinfo();
?>
http://tanaka.sakura.ad.jp/2011/05/centos-linux-apache-php-perl-mysql-lamp.html
↑これを参考に適当に変更してみた
MaxClients 256 ←これを40に
MaxRequestsPerChild 4000 ←これを1000
このサーバは、512MBしかないからもっと小さくしたほうがいいのかも。。
# ab -c 10 -n 100 http://iphone-xvideos.info/
【変更前】
Requests per second: 40.01 [#/sec] (mean)
【変更後】
Requests per second: 137.57 [#/sec] (mean) ←1発目
Requests per second: 552.79 [#/sec] (mean) ←2発目以降(キャッシュ後)
最新版をやってみるとエラーが発生。
「サーバーの PHP バージョンは 5.1.6 ですが WordPress 3.4.2 は 5.2.4 以上のみでご利用になれます。」
3.1系を選択する。。
http://ja.wordpress.org/releases/
※↑結局、後日phpとmysqlのバージョンアップをやりました。
ソースをUP
DBを作る
ホームの「新規データベースを作成する」と書いてある所の下にある、
を修正する。
【プラグイン】
WPtouch ←/wp-content/plugins/wptouch/themes/core/core-header.php をちょこっと変更すればiphoneでxvideo再生ができる。
○人気記事一覧
http://the-fool.me/wordpress/plugins/wordpress-popular-posts.html
設定⇒投稿設定⇒Atom 投稿プロトコル&XML-RPCにチェック
キャッシュが効いていて問題ないことを確認。
○wikipediaから取ってきた女優名をカテゴリテーブル(wp_terms)に突っ込む。(5,260人でした。)
↑これは月に2回更新。cronで動かすことにした。
○googleブログ検索(24時間以内のもの)に女優名をつっこんで、
(とりあえず、引退した人の動画は少ないだろうと考え、現役2,762人分のxvideosを取得してみた。処理時間8時間、192件取得できた。)
http://www.kaasan.info/archives/1457
動画のURLを取得したら、削除されていないか調べて、OKだったら投稿。
http://www.multiburst.net/sometime-php/2009/04/newpost-with-wordpress-xmlrpc-api/
↑ここらへんを参考に
http://pear.php.net/package/PEAR/download
↑pear自体はここにあるので、「XML」フォルダのみをUP。
だいたい、30分で10記事取得できることがわかったので、
【cron設定】
$ crontab -e
00 04 * * * /bin/sh /home/ユーザーID/iphone-xvideos.info/insert_X.sh >/dev/null 2>&1
00 03 1,15 * * /bin/sh /home/ユーザーID/iphone-xvideos.info/insert_XXX.sh >/dev/null 2>&1
http://miya0.dyndns.org/pc/settei/crontab.html
----------------------------------------------------
↑旬な情報が取れないが、とりあえず。。
前日のterm_idを記録して、
次の日はそれ以降のデータを取得する。
----------------------------------------------------
☆jqueryでお気に入り作成。cookieを使う。(PCのみ?)
☆好きな女優を登録しておけば、記事の更新情報をメールで通知。
☆デザイン修正。。
実際、なんとなく勉強になった気もするし、楽しく作業できました。
まったくアクセス無くても、自分用にとても良いものができたと思っているので満足です。
もし繋がりにくくなったりしたら、
別のレンサバに変更しますー。
随時こちらに追記していきますね。
最後まで読んで頂いてありがとうございます。
サイトオープンから10日ほど過ぎたので状況をお知らせします。
はてぶは全くだめだった。。
(日々増加しているが、検索エンジンからくるようになってもまだこんだけ。。)
メモリは問題なし。512MB中ピークでも300MBぐらいしか使ってない。
# chmod 744 /usr/local/bin/memrep.sh
※本日、テスト的にDMMの広告を張ってみました。。←すぐ消した。。
また、後日お知らせしますね。
1か月経ったので。。
ページビュー2500/日
自動更新なのに、きっちりアクセスは日々増えて続けています。エロは強い。
アクセス少ないので、負荷は全く問題なし。
Swapも全く使ってない。
サイト作ったよー! - はてコま! | はてブコメまとめ B!
このサイト作っていろいろ確認とかして「さーて公開」って思った矢先に自分の作ったサイトからこんな記事見つけて「うひゃー!」ってなりましたw
はてなブックマークのトップページって、正直なんか飽きちゃったし、スクロールせずに表示できるのが数エントリーだけで、やたらヘッダがでかかったり、広告がでかかったり、欲しい情報がほんのちょっとしか表示されないし、気のせいかエロいサイトのサムネイルが表示されなかったり、デザインもまじめくさいし、改善したらもっともっと使いやすくシャレオツになるし、アクセスも稼げるんじゃないのって思います。
私も自分のサイトを作ろうと思った経緯はこの方とほぼ同じです。。公式って少し見辛いって思っていました。
そんなときにはてブ1000users超え記事アンテナ(´・ω・)|トップページを見つけて「あぁ自分で作るか」ってなりました。
週6フリーターさんがいろいろと使用したものを紹介してくれて、あまり技術のない自分でも作ることができました!
この場をお借りして、お礼を申し上げます。ありがとうございます!
では、恒例化している感じがする、サイト作成にあたってのご報告です。
使い方はいたって簡単。タグを選ぶか検索すると最近のはてブ100以上の記事があがってきます。
最初、サイトを作るにあたって「フリーターさんのものと差別化したいなぁ」と思ったので、私は"はてブエントリーのコメント"を"見る"ものに仕上げようと思いました。
なんでコメントを見たいと思ったかという原因はこちらの記事です。
この記事を読んでる人にも感じた人がいると思うのですが、タイトルを読んで「?」となりませんか?
記事を読み進めていくと更に「NSLog」が問題なのか??と混乱しませんか?
最初のタイトルの印象が強すぎて、はてブのコメントを読んでやっと正確に判断できました。
なので、コメントをもうちょい読みたいなーと思い、こういったサイトにしました。
それと、フリーターさんのとこに書いてあるものを参考にさせてもらってます。
本当にありがとうございます。
Webサービスを作ったことがなかったのですが、HTMLやCSSは知っていましたので、ほとんどVimでコーディングし、ブラウザで確認するという普通の作業をしていました。
phpは勉強したことがなかったので、わからないことがあれば都度ネットで検索していました。
JavaScriptでFeedを取得したり、PHPを使ってAPIからJSONを取得など、ファイルがまとまっていない感があります。
実は、bootstrapで作ったナビゲーションバーのドロップボタンがスマフォだと押せないんですよね。。
こういう問題があるときにフレームワークを使ったのを後悔しますよね。
実に手軽に使えるbootstrapですが、なんとなく使うのはオススメしません。
ネット上には他にグリッドシステムだけや、違う素材を配布しているサイトがあるので、俺俺フレームワークを作ることをオススメです。(でも、まとまっているという観点でbootstrapは使いたいですよね。)
サーバーはさくらインターネットのホスティングサーバーを使用しています。
初めて、こういったサービスを作ったのですが、小さい微調整に非常に時間がかかりますね。
見難い、見易いを考えながらコードを変更して、ブラウザで確認して・・・を繰り返すのは時間がもったいないですね。どなたかいいノウハウをお持ちではないでしょうか?
みなさんも、こう立て続けにはてな関連のサービスが立ち上がると自分でも何か作りたくなりますよね。
思ったら作って便利な世の中にしましょう!えいえいおー!
gdk使ってるので最近デバッグメッセージが出るようになってウザいのがあったから出なくしてみた。
スイッチとかノブとか探したけれど無いっぽいので仕方なくパッチ書いた。
結局何したかといえば、g_log_set_handlerでデバッグレベルのハンドラに何もしないダミー関数セットした。
例えばPackageKitの場合、
static void gpk_debug_ignore_cb (const gchar *log_domain, GLogLevelFlags log_level, const gchar *message, gpointer user_data) { }
g_log_set_handler ("PackageKit", G_LOG_LEVEL_DEBUG, gpk_debug_ignore_cb, NULL);
と初期化する。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか? 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の,変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか? 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か? 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者/消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し,処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か? 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか? 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的/手続き的方法 10.2 宣言的/手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中,後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し,使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
■異性の好みを探る簡単な方法
これは私の長年の統計学的経験論なのだが(つまりいい加減てことですね)
異性の好みや接し方を簡単に推測する方法がある。
それは、
「どんなゲーム機が好き?」
って聞いてみることだ。
好きなゲーム機は?と聞いて「任天堂機」(但し64DDとバーチャルボーイを除く)を挙げる人は、かなり保守派だ。
堅実派、浮気しない人、安定した職業についた人、配水管の技術者を好む傾向がある。
また平均的な異性を好む。必ずしも美人(イケメン)である必要はない。逆に派手な異性は苦手。
「セガ機」あるいは「ソニー機」「ピピンなんとかかんとか」「パナソニックのやつ」等をメーカー名や国名で挙げる人は、
基本的にブランド志向なので、他人から見て自分の恋人がどのように見えるかをとても気にする。
男性なら高収入、医師弁護士などの職業が優先事項。ルックスは良いに越したことはないがそれよりも財力と権力(役職とか)
女性なら体育会系のがっしりした男性を好む。自分より背の低い男性は基本NG。マッチョOK
男性ならバストの大きさをとても気にする。基本的に巨乳好きというか貧乳は許せないタイプである。
「セガサターンの黒」とか「四角ボタンの頃のファミコン」みたいな一般人はあまり知らないような特定の固有の機種名を挙げる人。こういう人はあまり特定の傾向がなく、好きな異性タイプもピンポイントである。たとえば女優のAは大好きだが(顔の似ている)Bは生理的にダメ、とか言うことがよくあるのでその微妙な違いが他人にはよくわからない場合もある。ただし好きなものはとことん好き、という人である。
また、特に男性の場合、ゲーム機の扱い方と女性の扱い方はとても良く似ている。
新品にこだわる人、これは処女にこだわる。中古ばかり乗っている人はその点はおおらかである。
ひとつのゲーム機を長く長く使う人。これはパートナーの異性をとても大事にする。基本浮気はしない。女性の場合は重すぎることも。
頻繁にあれこれとゲーム機を買い換える人。こういう人は異性も簡単に乗り換えるし浮気が多いので要注意である。
メモリーカードを初期化ばかりしてる人や、ファームウェアに改造をたくさんする人は、ある意味独占欲が強いのだろう。暴力傾向があるのでこれも要注意。パートナーをとても大事に(誰にもちょっかいを出させない、縛る)するが、ひとたび浮気でも疑われると暴力沙汰になりたいへんな思いをする。
補足2
ゲーム機に興味がない、ゲーム機なんて遊べれば何でもいい。という人は、恋愛においても受け身。基本的に自分からは告白しない。逆に押し続ければ落ちるタイプである。異性にこだわりがない代わりに、自分を愛してくれる人、が好き。基本的に自分が一番大事なわりに自分に自信がないのだと思う。
補足3
変にハデでなくて、オタク臭くなくて、コントローラーが持ちやすくて、空冷がそれなりにちゃんと効いて、音楽や動画もそこそこ楽しめるゲーム機がいい。
という人は、基本的に相手を道具としてしか見ていない。ちゃんと稼いで浮気もせず家に帰ってきてくれればそれでいい、亭主元気で留守がいい、というタイプである。こういう人はスペックで相手を見るので、決して高スペックは望まないが堅実でしっかりした職業の人、それもできれば家柄がいいほうがいい、というタイプ。自身も庶民であるか、逆に超お嬢様で世間知らずな人かのどちらかである。
俺が知らないだけなのかもしれないが
.Net Framework 3.5や4をインストールしようとすると
必ずネットから最新版をダウンロードor最新版の確認をしようとする。
もしくはとても不安定。経験上、たまたまではなくていつもそう。
まるでマイクロソフトは.NET Frameworkを使ってほしくないみたい。
こいつ1つセットアップするために、もう30分待っている。
ちなみに
仕事も進まんし、段どりがくずれて萎えさせられるし、個人的にも腹立たしいわ。
わりとすぐにインストール完了できた。
今だに2MB/73MB。
「転送速度は0kB/秒です」「500kB/秒です」「接続を初期化しています」を繰り返す。
なので、2.0のFull版に切り替えることにする。
ペロペロ
1. htmlのはき出しがあるやつは?>を書いたほうがいいよ。それ以外は最近はかないのがはやりだねさらに昔はevalとかで書いてた
2. configこれはwwwやpublic_html以下にしかconfigを配置できないクソサーバーがあるので、phpにしておいたほうが安全。なぜなら丸見えにしてあれこれパスをさらけ出すバカがいるかもしれないからだ。オープンソースなら特に。
3. コメントは挨拶だ。必要以上に挨拶を繰り返す必要もないし、それ以上でも以下でもない。
4. eclipseのせいと、phpとかが出始めたころのコーディング規約がスペースにするように求めた。{を改行してから書くか、続けて書くかのこれは宗教戦争だ。だが正直スペースは気に食わない。LLのくせに何バイトつかってるのだとおもう。あとスペース2文字インデントのやつは旅立て!
5. phpの0と""の違いは緩すぎる。そういう意味でナンバーの取り扱いにだけは気を配るべきだ。あとはtmpでもbufでもretでもなんでもいい。
6. nullはつっこむな、nullで初期化はすんな。初期化されてないからnullなんだ。issetは有効につかえ。とくに$_系の変数
7. 本当はerrorprocをかけといいたいがLLにそこまで望んでもしゃーない。エラーを投げると鯖ログにまで場合によっては落ちたりしてやっかいだからfalseを返せばいいというものでもないが、trueで初期化するやつは滅びていいと思う。あとarrayを返すようなfunctionの場合、phpのなんだっけisarray?だっけ?がクソすぎて萎える
8. つかダブルクオートのなかに$を書くコードは滅びていい。コンストはすべて大文字でという昔ながらのルールだけ守ってくれればいい
9. 出力系のラップ関数ぐらいつくっておこうぜ。あと、var_dumpとかのほうが見やすい。あと、get_defined_varsとかをラップしておくと便利
10. 三項演算子はつかうな。ifの{}を略すな。可読性がおちるのとしんたっくすで原因の特定がめんどくさい。
12. ++iなんていうコードを書くな。あと、roopの条件文で計算すんな
13. むしろこういうのは文字列の連結以外で使うようなスチュエーションをつくっちゃだめ
14. あら上で言っちゃったよ。ここまでやるんだったらlogファイルに吐き出すところまで拡張しとけば?
15. んー。エラーメッセージを定数化するときは外国版をつくるあてまである時だけだな
16. これも上でいってしまったな。あとリロードされてもいいように初期化でクリアしておくといいぞ。
17. ああそうだな、関数が1スクロールに収まらないときは大抵正規化に失敗してる。つくりをみなおせ
18. えー、こんな風に書くのはどうかしている。public二つチェインで呼び出すぐらいなら、内部でprivateを呼び出すか、継承させてparentにしておくべきか、それともシステムとして共通のstaticで呼び出せるかにしてくほうがいいのでは?$this->setThis()でいいじゃないか。なぜpublic functionをそういくつも定義する必要がある? 外部からの入り口出口は絞れ
19. グローバルなラッピング関数は最低限にとどめるべきで他は機能ごとにクラスつくってメソッド化しとけ。p(var)じゃねぇよDEBUG::p(var)とかにしとけってことだ
20. 眠くなったからねる。つまりはそんなもんだってことだ。気に病むな。満足してもらえるもんをしっかりつくればいいだけだ
http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/
良いPHPerだって?そんなものは丸めてゴミ箱にでも捨ててしまった方が資源の再利用になる分いくらかマシだ。
つまり俺たちがしなくちゃならないことは「より良いPHPerにならないため」に何ができるかってことなのさ。
それじゃ、始めよう。
?>なんて使っちゃいけない。そう俺たちはBAD PHPer。
無駄なホワイトスペースの出力に悩まされるくらいなら対称性なんて丸めてゴミ箱にでも捨てた方がまだマシだ。非対称性こそが賛美。
require_once("config.php");
未だにこんなことやってるやつがいるのかいベイベー。絶対にダメだ。この一行を見たら俺は悶絶する。
ダメだ、早く何とかしないと。
大抵このconfig.phpの中身はこうなっている。見て絶望だ。
$hoge_path = ''; if (!LOCAL) { define('FOO_FLAG', 1); if (HONBAN) { define('HOGE_FLAG', 1); } else if (TEST) { define('HOGE_FLAG', 2); } } else { $hoge_path = '/local'; define('FOO_FLAG', 2); define('HOGE_FLAG', 3); } define('HOGE_URL', $hoge_path.'/hoge/');
こういうのが延々と続くわけだ。もういやだ。もう見たくない。
本番環境とテスト環境でどういう値の違いがあるのか、ローカル環境だとどうなるのか、まったく把握できる気がしない。
なまじPHPな設定ファイルのせいで、処理をついつい書いてしまう。そしてどんどん複雑になってしまう。
やはり設定データは基本的にYAML等のデータしか定義できない形式のもので用意すべきだ。そして環境ごとに設定ファイルを分けるべきである。
そうすることで何にどういう違いがあるのかすぐにわかるし、diffすれば一度にすべて把握することができる。
# 本番環境設定ファイル foo_flag: 1 hoge_flag: 1 hoge_url: '/hoge/'
# テスト環境設定ファイル foo_flag: 1 hoge_flag: 2 hoge_url: '/hoge/'
# ローカル環境設定ファイル foo_flag: 2 hoge_flag: 3 hoge_url: '/local/hoge/'
// ここで後の処理のためにhogeメソッドを呼び出しておく $q->foo(); // $a['foo']はここに来る時点で真のはず // 2010-03-10 判定がおかしいので修正 // 2010-06-21 やっぱり値が入ってる方が正しい if ( !isset($hoge[0]) ) { }
コメントは保守されない。そう、それは真実。こんなコメントを発見したら即効削除しよう。コメントは基本信じるな。
俺たちにちょっとしたヒントと大きな損害を与えてくれる、それがコメントの役割なのだ。
わかる。いいたい事はとてもわかる。俺たちはしばしばインデントにスペースを使うはずだ。一方でIDEのしっかりした言語ではタブも使うことがある。しかし悪いことに、両者を混同しているプログラマも一定数いるのだ。
タブを画面上で認識しにくいエディタが世の中には存在する(何とは言わないが)
そして画面上で認識しにくいことを理由にタブを気にしないプログラマがいる。
この二つの条件が重なると、タブとスペースの交じり合ったインデントが完成する。もうぐちゃぐちゃだ。これは永遠に続く戦いだ。
私たちが勝利を掴むためにできることなどせいぜい、常にスペースしか使わない。タブを見つけたらその都度スペースに変換する。そういった地道な活動が明日へとつながるのだ。
われわれがプログラムをするとき、何に一番時間がかかってるか。実は変数の命名なのである。ここで拘り過ぎて時間をかけ過ぎては何も進まない。
御託はイイからさっさと書け、だ。しかしとはいっても変数名は重要。日頃からどういうときにどんな名前を使うかを決めておくといい。
そして変数名に型はまったく必要ない。型宣言のないPHPにおいて、型の変数名をつけること自体ナンセンスだ。
$iNumber = 'aaa';
になんの意味もない。コメントを信じるなでも言ったが、これはプログラマを混乱させるだけの害悪なものだ。
変数を使う前に初期化するのは、警告を出さないという意味でも良い癖だ。しかし具体的にどこでやるかが問題だ。
$foo = null; $foo = $q->foo();
こんな初期化に意味はない。よくあるのはやはり、if文で値を振り分けるケースだろう
$foo = null; if ( $hoge ) { $foo = 1; } else if ( $bar ) { $foo = 2; }
このときの初期化はとても有効だ。もしnullの初期化を忘れたまま$fooを使うと警告が出るが、ちゃんと初期化してるので出ない。基本中の基本だ。
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; return $bReturn; }(中略)
もし、何かしらの理由で、あなたの書いたif文が間違っていたら?
この書き方をしていれば、間違った値に対して、常にfalseが返る。
私たちが、PHPでsensitiveなデータを取り扱うなら、正しいデータが入力されるまでは、動かないコードを書くべきだ。
trueとfalseの条件がいまいち明確ではないが、本当に動かないコードを書けというのであれば以下のようにすべきだ
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; else if ($i == 1) $bReturn = false; else throw new Exception("bad status! $i"); return $bReturn; }
中途半端にfalseを返して生存させる必要性はまったくない。今すぐ死ね!
連想配列のキーを指定する場合だけ定数と間違わないようにクオートで囲まなければならない。そして逆に定数を使いたい場合はクオートで囲ってはいけない。
更に後世のプログラマが処理を見たときに、定数が使いたかったのか、文字列が使いたかったのかを明確にしたい場合はconstantを使うと良い。
// 定数のFOOを使うよということが明確になる print $a[constant('FOO')];
もし、文字列を変数の値と一緒に出力するとき、PHPではコンマの代わりにprintfを使うことが使える。
printf( “Hello, my name is %s“, $sName);
以下の代わりに上記のコードを使う。
echo “Hello, my name is “, $sName;
出力すべき変数が増えれば増えるほど、有効になっていく。とにかく迷ったならば、printfを使え、だ。
三項演算子はとても有効だ。しかし優先順位に難があるせいで、三項演算子をネストしようとすると以下のようなコードになってしまう
$n = (($i == 1) ? 2 : (($i == 2) ? 3 :$i));
括弧だらけで読みにくいったらありゃしない。三項演算子を使うなら一回まで。約束守れないやつは丸めてゴミ箱にでも捨てちまえ。
if ( $flag ) { }
仕様をちゃんと把握しているなら真偽値のチェックなどこれで十分。
もし事前にbool型だというのが確定してるのなら「$flag === true」を使えばいい。
インクリメント、デクリメント演算子は前に付くか後ろに付くかで意味が変わるので慣れるまでは非常にややこしい。
わけがわからなくなるくらいなら初めから使わないほうが良い。見極められないなら使うな。それがPHPerなのだ。
文句なしだ。これは文句がない。
他にも色々あるので覚えておこう
$a %= 1; $a &= 1; $a |= 1; $a ^= 1; $a <<= 1; $a >>= 1;
てっとり早く画面に表示する際にpreはよく使うが、デザインの関係上画面の文字が見えないときがある。
なのでdivを使って以下のようにしとくと便利だろう。
function p($var) { echo "<div align='left' style='background-color:white;color:black;'><pre>"; print_r($var); echo "</pre></div>"; }
君らが通常作るアプリケーションなんぞに、定数なんぞ必要ない。いいか、もう一度言う、お前ら程度のもんが、定数使おう何ぞ、おこがましいわ!
大丈夫。なんでもかんでも定数にする必要はない。結局設定ファイルに定数をずらずら作りまくってわけがわからなくなってるパターンが多い。
貴様みたいなもんに、定数は制御できん。いいか設定ファイルはYAML等のデータで持つようにし、その連想配列のデータ構造を一つ持ってるだけで定数の変わりになる。
このメリットに比べれば、定数だと書き換えられなくて良いという利点などこの歯のカスほどのものだ。そんなものは丸めてゴミ箱へ捨ててしまうといい。
認識を改めろ。俺たちはより良いPHPerにならないために努力している。
class Request { private $parameters; private $method; function __construct () { $this->method = $_SERVER['REQUEST_METHOD']; if ( strtoupper($this->method) === 'POST' ) { $this->parameters = $_POST; } else { $this->parameters = $_GET; } } function param ($key) { return isset($this->parameters[$key]) ? $this->parameters[$key] : null; } }
これだけでもいい。たったこれだけでもとても便利だ。ここから拡張してGETやPOSTを明示的に取るメソッドとかも作ってみるといい。自分の手を動かすのだ!
例が良くない。こんなのは引数が20個ある関数から、setを20回呼ぶオブジェクトに変わっただけではないか。
そもそもこの20個の引数とはなんなのか。何かのデータ構造なんであれば連想配列にして引数一つとして渡すべきだし、それぞれまったく異なる用途の変数なのであればWindowsプログラミングじゃあるまいし、20個も引数取る時点で設計が間違えている。
何がいいたいか。別に関数でもオブジェクトでもどっちでもいいということだ。
そんなことで悩んでる暇があったら設計を見直せ。
スキあらば自分自身を返せ。スキあらばオブジェクトを返せ。配列はArrayObjectのARRAY_AS_PROPSで返せ。
ひたすらメソッドチェイン。来る日も来る日もメソッドチェイン。とにかくメソッドチェインを使い続けろ。そこに未来はある。
どんなコードも繰り返すな。もし、少しでも同じコードを書いていたなら、それは関数に置き換えてしまえ。
・・・と、いうのはやめなさい。
一見同じように見えた処理でも前後の流れでまったく違うものということが往々にしてある。
まとめ方にも問題があるケースもある。何でもかんでも関数化すると、関数が膨大に増えていく。君は見たことがあるだろうか。common.phpやfunction.phpの恐ろしさを。
確かに細かく関数化はされているが、適切に関数化していないのである。結合度が非常に高い。なんでもかんでも盲目的にまとめれば良いという話ではないのだ!
あまりに極度に意識しすぎると、プログラムそのものができなくなる。そういう状態に陥る。
気を抜いて。そう気を抜いて。所詮あなたのコードなんてすぐに消えてなくなるよ。きっともっと偉い人が作り直すよ。だからまずは思うが侭にやるといい。
結合度を減らすというのは非常に難しい。何度も何度も失敗し続けて、ようやくここは分けた方が良かったんだなと気付く。次に活かそうと心に決める。そしてまた同じ過ちを繰り返していくわけだ。
まずは実装することだ。これが一番の早道だ。まずはがっつり結合した関数をあえて作るといい。何も考えずに作ろう。
そしてその後に、一部分使いまわしたいとおもうことがあるはずだ。その時に関数に切り出そう。それを繰り返すといい。そのうち初めから分けた方が良いと気付く。
何事も経験が必要である!経験を積まないプログラマは丸めてゴミ箱に捨ててしまえ。
さて、先の例で言うならば、私ならadd_result_outputという関数を作ってしまうだろう。だって、addとresultを連続して呼ぶのはめんどくさいんだもん。一連の流れをいつも使うのなら、その流れをやってくれる関数を作ればいいじゃないか。
function add_result_output ($iVar, $iVar2) { $r = add($iVar, $iVar2); echo result($r); }
もっと言えばクラス化してしまってもいいかもしれない。どんな感じになるかは君の手を動かして確認しよう!
このTipsはとてもわかりにくく、ニッチ過ぎる部分も多いかもしれない。
あくまでも「より良いPHPerにならないための20Tips」なのだ。
君はこの記事を鵜呑みにしてはならない。PHPをPHPと見抜けないPHPerはPHPを使うのは難しい。
もし、あなたがPHPプログラマなら、公式のPHPドキュメントはあなたのケツの穴を拭くための紙になるだろう。
私は、それぞれのセクションを眺めて、各関数でどんなことが出来るかなんぞ、歯クソのゴミ程に役に立たないとおもっている。動けばいい。はは。
あなたは、PHPで用意された既製関数で多くのことが実現できることに、(俺の仕事を減らすなと)驚くはずだ。
この記事があなたの役に立たない事を。
ふざけんな!