時間的には「+9:00」なので何の問題もないのですが気持ち悪いので毎回変更しています。
きっとどこかの設定が「東ティモール」になっているんでしょうね。
 |
| 赤丸をしたところが問題のところ |
2015年4月22日
Google+のイベントのタイムゾーン
Google+のイベントをよく使うのですが、そのデフォルトのタイムゾーンが「日本の東京」ではなく、「東ティモール」になっているのがとても気になる。
時間的には「+9:00」なので何の問題もないのですが気持ち悪いので毎回変更しています。
きっとどこかの設定が「東ティモール」になっているんでしょうね。
時間的には「+9:00」なので何の問題もないのですが気持ち悪いので毎回変更しています。
きっとどこかの設定が「東ティモール」になっているんでしょうね。
AWSのコンソールが日本語化された
AWS(Amazon Web Services)のコンソールが日本語化されました。
これで、これってなんだろう？ってのが短時間で解消されそうです。
でも、英語版を見慣れていたせいかなんかスッキリしない感じがします。
【AWS発表】AWS マネージメントコンソールの日本語対応
これで、これってなんだろう？ってのが短時間で解消されそうです。
でも、英語版を見慣れていたせいかなんかスッキリしない感じがします。
【AWS発表】AWS マネージメントコンソールの日本語対応
2015年4月18日
Gitを使う前にgit svnで練習がよいのかな？
近い将来プログラムソースのバージョン管理をGitに切り替えていこうかと思っています。
現在は、Subversionでやってます。
いきなりGitってのも良いのですが、Gitを使ってSubversionのリポジトリを使うためのgit svnというのがあるというのを知りました。
Subversionを捨てて、Gitに移行してもよいのですが慣れていないツールを使って振り回されて本来やりたいことができなくなると困るのでね。
新しいプロジェクトが始まったら、Gitを本格的に使っていくことにしました。
で、git svnは。
やっていることは、以下の以下のとおりです。
準備
現在は、Subversionでやってます。
いきなりGitってのも良いのですが、Gitを使ってSubversionのリポジトリを使うためのgit svnというのがあるというのを知りました。
Subversionを捨てて、Gitに移行してもよいのですが慣れていないツールを使って振り回されて本来やりたいことができなくなると困るのでね。
新しいプロジェクトが始まったら、Gitを本格的に使っていくことにしました。
で、git svnは。
やっていることは、以下の以下のとおりです。
準備
- Subversionのtrunkをコミット毎にローカルのgitリポジトリに取り込む。
完了すると、ローカルのgitでバージョン管理ができるようになる。
運用
- プログラムソースを修正する。
- 修正したソースをステージングへ追加する。
- gitのリポジトリにコミットする。
↑ここまでが通常のGitの操作 - git svnでsubversion用のコミットをする
git svn dcommitコマンドでSubversionのリポジトリにコミットする。
かるく動かしてみたらできたので行けそうです。
これの何がいいかというと、Subversionの場合、リポジトリが見えてないとコミットできないので直したものがどんどんたまって、ポイント毎に戻りにくくなってしまいます。
ですが、Gitであれば、ローカルのGitリポジトリに対してコミットをできるのでポイント毎に戻ることができるようになります。
Subversionのリポジトリが見える環境では、Subversionを使って、つながってない時はgit svnを使ってローカルにコミットをためる。で、Subversionが見えるタイミングになったら、dcommitをしてSubversionにコミットです。
これで、どこでもソース管理ができるという寸法です。いかがですか？
本当はGitを直接使うのが良いので早くGitに移りたいです。
OSも関係なく、コマンドラインでもさくさくと作業ができればプロっぽいですよね(笑)
Git svnの使い方サイトとか
データフォーマットって大事だよという話
残念なことは続くよねー。
移行データを作って送ってもらったのはいいのですが、フォーマットが違うため使うことができないです。
初めて送ってきたんだったら何かの間違いと思って何も思わずに、直してくださいと言うんですが、それが何回も続くと大丈夫かこの人？ってなってしまいます。
前回も違っていてそれを指摘すると、自分の責任ではなく業者の問題とかって言って、逆に叱られたんですよね。でも、そんなのには負けずに言い返しますけどね。
本当の期限が迫っているので、それまで送られてくればいいんですが…。
もう、リリースを何回も伸ばしてるんだからこれが最後だろうな。
移行データを作って送ってもらったのはいいのですが、フォーマットが違うため使うことができないです。
初めて送ってきたんだったら何かの間違いと思って何も思わずに、直してくださいと言うんですが、それが何回も続くと大丈夫かこの人？ってなってしまいます。
前回も違っていてそれを指摘すると、自分の責任ではなく業者の問題とかって言って、逆に叱られたんですよね。でも、そんなのには負けずに言い返しますけどね。
本当の期限が迫っているので、それまで送られてくればいいんですが…。
もう、リリースを何回も伸ばしてるんだからこれが最後だろうな。
2015年4月10日
テキストエディタを変える宣言をしたにもかかわらず
テキストエディタをSublimeTextからatomに変更すると宣言したにもかかわらず、未だに移行できず。
理由は、画面分割をした時にマウスでサイズ変更ができないようなんです。
キーボードでできるようにするプラグインがあるようですが、キーボードで操作する為の練習をしないとならないということでなかなか次の一歩が踏み出せません…。
でも、いつか必ずや！
理由は、画面分割をした時にマウスでサイズ変更ができないようなんです。
キーボードでできるようにするプラグインがあるようですが、キーボードで操作する為の練習をしないとならないということでなかなか次の一歩が踏み出せません…。
でも、いつか必ずや！
2015年4月8日
やっぱり自分の開発環境は最高
出向先から舞い戻ってきて(*1)自分の事務所で開発作業をしてるのですが、やっぱり日頃使い慣れている環境での作業は快適だし、捗りますよね。
いくらCPUが早いPCだったとしても画面解像度が低いと効率の良い開発はできなです。
自分のディスプレイの解像度が高過ぎる(2,560X1,440)のだと思いますが、ノートPCでメインの開発はやっぱり無理があります。
あと、キーボードが手に馴染んでいるかもとても大事です。
ワープロやってるだけだったらいいけど。
*1
出向先に居てもプロパーの人が他の作業につきっきりでなにも進まないのでここに居なくてもいいですよねと言い続けて作業することになりました。
いくらCPUが早いPCだったとしても画面解像度が低いと効率の良い開発はできなです。
自分のディスプレイの解像度が高過ぎる(2,560X1,440)のだと思いますが、ノートPCでメインの開発はやっぱり無理があります。
あと、キーボードが手に馴染んでいるかもとても大事です。
ワープロやってるだけだったらいいけど。
*1
出向先に居てもプロパーの人が他の作業につきっきりでなにも進まないのでここに居なくてもいいですよねと言い続けて作業することになりました。
まぁ、やるべきこともいまいちあやふやですが目指すところはだいたい理解できたので自分の理解のなかで進めることになっています。
で、週１で見せて整える作戦です。
うまくいくかどうかわかりませんが挑戦中です。
出向先の人(会社)も新しいことに挑戦の年だということで了承してくれたのだと思いますが…。
2015年4月2日
Vagrant使って開発してみます
Vagrantというオープンソースのソフトウェアがあります。
仮想環境をソフトウェアで簡単にコントロールすることができるツールです。
予め作っておいたOSのイメージをとっておくことで簡単環境を再構築をしたりすることができます。
自分は、Windowsがメインの環境なので、Linux上で動くWebのアプリケーションとかは、Windows環境で開発、単体テストをしてから、Linux上デプロイして再度テストをするということをしていました。
Linuxのディレクトリにファイルを置くのは、むずかしいというか一手間必要だったりするのでちょっと面倒だと思っていました。
ですが、Vagrantを使うと仮想環境のLinux上のディレクトリをクライアントPC(Windows)フォルダのマッピングを簡単にやってくれるのでそのフォルダ上で開発をすることで直ぐのデプロイしたことになるのでちょー便利です。
で今回はこんな環境で開発をします。
作るアプリの運用環境
（※本当の運用環境は、aws上ですけどね）
- OS:CentOS
- Webサーバ:Apache
- 開発言語:PHP
- DB:MySQL
開発で使うツール達
- OS:Windows7
- DBツール:A5:SQL Mk-2
- テキストエディタ:Atom
- 仮想環境:VirtualBox
- 仮想環境構築ツール:Vagrant
当分、この環境でシステム開発したいなーって思いますわ。
登録:
投稿 (Atom)