MEANと私（出会い編）
2016年01月29日
MEANと私（出会い編）
こんにちは、
プログラムを書くより要件定義や外部設計をやってる方が多い私です。
けれど、やっぱりプログラムは好きなのと
何か新しいものをやりたいなぁという好奇心から
ちょっと前から気になっていた、
従来の
「クライアントからのリクエストでの応答する」のではなく
「サーバーからクライアントへプッシュする仕組み」について調べていたら
MEAN Stackに出会いました。
LAMPに代わる次世代の構成とのこと。
おい、大きく出たな。
MEAN Stackの特徴は、
・サーバーとクライアント両方の面倒を見てくれる
・言語はJSのみ
・サーバープッシュ型なので利用者が更新ボタンを押さなくても情報を提供できる
他にも何か書いてあったけど、眠たくなってきたので、そっとタブを閉じました。
要は、JSだけでサーバーサイドからクライアントまで全部作れる簡単な仕組みだよってことかな。
そうに決まってる。
ついでにMEAN Stackで探すと必ず出てくる説明ここに書いときますね。
MEAN Stackとは、システムを構成する技術の頭文字を繋げたものです。
M MongoDB
E Express
A AngularJS
N Node.js
+ Stack（まとめるって意味）
Node.js以外は聞き覚えのないものばかりだ。
ついでにLAMPは
L Linux
A Apache
M MySQL
P PHP
LAMPはOSがLinuxで固定になってるけど
MEANはMAC、Linux、Windowsで使えるとな。
へぇー
Linux限定だったら
ラーメン（LAMEN）になってたのに・・・残念。
実際に流行っているのか調べてみたところ
Googleトレンドで見たらこんな感じ
２０１４年あたりからグイグイっと上昇してる。
国でいうとインド、アメリカ、カナダ、オーストラリア、ふむふむ、日本は、なしと。
アマゾンで書籍を探しても、なし・・・
こ、これは、あれか
ビックウェーブがくる前兆か
よし、この波に乗るためにちょっと先に勉強して
作ろうと思ってた趣味（ネトゲ）のサイトもこれで作ってみよう。
使えそうだったら業務にも活用してみよっかな！（お許しが出れば）
こんにちは、
プログラムを書くより要件定義や外部設計をやってる方が多い私です。
けれど、やっぱりプログラムは好きなのと
何か新しいものをやりたいなぁという好奇心から
ちょっと前から気になっていた、
従来の
「クライアントからのリクエストでの応答する」のではなく
「サーバーからクライアントへプッシュする仕組み」について調べていたら
MEAN Stackに出会いました。
LAMPに代わる次世代の構成とのこと。
おい、大きく出たな。
MEAN Stackの特徴は、
・サーバーとクライアント両方の面倒を見てくれる
・言語はJSのみ
・サーバープッシュ型なので利用者が更新ボタンを押さなくても情報を提供できる
他にも何か書いてあったけど、眠たくなってきたので、そっとタブを閉じました。
要は、JSだけでサーバーサイドからクライアントまで全部作れる簡単な仕組みだよってことかな。
そうに決まってる。
ついでにMEAN Stackで探すと必ず出てくる説明ここに書いときますね。
MEAN Stackとは、システムを構成する技術の頭文字を繋げたものです。
M MongoDB
E Express
A AngularJS
N Node.js
+ Stack（まとめるって意味）
Node.js以外は聞き覚えのないものばかりだ。
ついでにLAMPは
L Linux
A Apache
M MySQL
P PHP
LAMPはOSがLinuxで固定になってるけど
MEANはMAC、Linux、Windowsで使えるとな。
へぇー
Linux限定だったら
ラーメン（LAMEN）になってたのに・・・残念。
実際に流行っているのか調べてみたところ
Googleトレンドで見たらこんな感じ
２０１４年あたりからグイグイっと上昇してる。
国でいうとインド、アメリカ、カナダ、オーストラリア、ふむふむ、日本は、なしと。
アマゾンで書籍を探しても、なし・・・
こ、これは、あれか
ビックウェーブがくる前兆か
よし、この波に乗るためにちょっと先に勉強して
作ろうと思ってた趣味（ネトゲ）のサイトもこれで作ってみよう。
使えそうだったら業務にも活用してみよっかな！（お許しが出れば）
[Rails]Railsのバージョンを上げたことでspatial_adapterが使用できなくなりました
2016年01月14日
遅くなりましたが、明けましておめでとうございます。
今年もよろしくお願いいたします。
さっそくですが、本題に入ります！
今回はRails4.2にて標準搭載となったActive Jobを使用したいために、Railsのバージョンをあげたところspatial_adapterが使用できなくなってしまった件について話していこうと思います。
標準のRailsではMySQLのgeometry型が取り扱い使いづらいため、使いやすくしてくれるgemです。
githubにて色々な方が公開されているため、実際に使用したものが気になる方はこちらをごらんください。
githubを見ていただいた方は、お分かりになったかと思いますが、
ActiveRecordのバージョンが3.2.0 and upとなっており、Railsのバージョンが上がったことで合わせてActiveRecordのバージョンが上がったので、対応していないバージョンになってしまいました。
どのようにエラーが出たかというと…
マイグレーションなど処理実行時に以下のようなエラーがでてしまいました。
原因箇所については、dbに関わりそうなgemを１個ずつ削って調査しました…
google先生にいろいろ教えていただいたところ、Rails4.2でgeometry型を扱うにはactiverecord-mysql2spatial-adapterを使用すればいけるとのこと。
ただ、インストールされているActiveRecordのバージョンが4.2だったため、今回はこちらのactiverecord-mysql2spatial-adapterを使用させていただきました。
ではマイグレーションから…
うまくいったので、次はgeometry型の値を取得してみます(実際には他にもテーブル生成しました)。
むむむ…
geometry型のはずの値が数値となっていました。再度いろいろ調べてみるとrgeoとrgeo-activerecordのgemが必要ということでインストールしてgeometry型の値を取得。
むむむむむむ…
結果は変わらず、geometry型のはずの値が数値となっていました。なにがおかしいんだと思いながらactiverecord-mysql2spatial-adapter-42のドキュメントを再読…
すると、db設定のadapterを「mysql2」ではなく「mysql2spatial」にするという記述があったため変更してgeometry型の値を再度取得。
見事geometry型の値を取得することに成功しました！
ちなみに、データについてはspatial_adapterのgem使用時に登録しておいたデータでも問題なくgeometry型の値を取得できましたが、どうやらspatial_adapterのバージョンが低いとそのままでは使用できず、sql文でgeometryからxy値を取得して変換をしないとエラーとなるようです。
Railsのgemは便利なものが多く、一度環境さえ作成できればかなり簡単に開発が行えるのですが、Ruby、Railsのバージョンを上げ、使ってたgemが使えなくなった際、どのgemが使えなくなったのか原因調査が難しく、代わりを見つける、または、自作しなければならないということになり、結構難易度が高いなーっと改めて実感しました。
gem周りについては、とにかく経験を積むしかないと思うので、また同じようなことがあれば情報共有ということで書いていければと思います。
では、今回はこの辺りで！
今年もよろしくお願いいたします。
さっそくですが、本題に入ります！
今回はRails4.2にて標準搭載となったActive Jobを使用したいために、Railsのバージョンをあげたところspatial_adapterが使用できなくなってしまった件について話していこうと思います。
spatial_adapterとは
標準のRailsではMySQLのgeometry型が取り扱い使いづらいため、使いやすくしてくれるgemです。
githubにて色々な方が公開されているため、実際に使用したものが気になる方はこちらをごらんください。
Rails4.2でのspatial_adapterのエラー
githubを見ていただいた方は、お分かりになったかと思いますが、
ActiveRecordのバージョンが3.2.0 and upとなっており、Railsのバージョンが上がったことで合わせてActiveRecordのバージョンが上がったので、対応していないバージョンになってしまいました。
どのようにエラーが出たかというと…
マイグレーションなど処理実行時に以下のようなエラーがでてしまいました。
$ bundle exec rake db:migrate
rake aborted!
NoMethodError: undefined method `type' for "varchar(255)":String
原因箇所については、dbに関わりそうなgemを１個ずつ削って調査しました…
Rails4.2では何を使えばいいのか？
google先生にいろいろ教えていただいたところ、Rails4.2でgeometry型を扱うにはactiverecord-mysql2spatial-adapterを使用すればいけるとのこと。
ただ、インストールされているActiveRecordのバージョンが4.2だったため、今回はこちらのactiverecord-mysql2spatial-adapterを使用させていただきました。
ではマイグレーションから…
$ bundle exec rake db:migrate
== 20151225060238 DeviseCreateUsers: migrating ================================
-- create_table(:users)
-> 0.0109s
-- add_index(:users, :email, {:unique=>true})
-> 0.0123s
-- add_index(:users, :reset_password_token, {:unique=>true})
-> 0.0134s
== 20151225060238 DeviseCreateUsers: migrated (0.0368s) =======================
うまくいったので、次はgeometry型の値を取得してみます(実際には他にもテーブル生成しました)。
$ rails c
Loading development environment (Rails 4.2.5)
irb(main):001:0> l = Location.first
Location Load (0.3ms) SELECT `locations`.* FROM `locations` ORDER BY `locations`.`id` ASC LIMIT 1
=> #Location id: 1, geom: 0
irb(main):002:0> l.geom.class
=> Fixnum
むむむ…
geometry型のはずの値が数値となっていました。再度いろいろ調べてみるとrgeoとrgeo-activerecordのgemが必要ということでインストールしてgeometry型の値を取得。
$ rails c
Loading development environment (Rails 4.2.5)
irb(main):001:0> l = Location.first
Location Load (0.3ms) SELECT `locations`.* FROM `locations` ORDER BY `locations`.`id` ASC LIMIT 1
=> #Location id: 1, geom: 0
irb(main):002:0> l.geom.class
=> Fixnum
むむむむむむ…
結果は変わらず、geometry型のはずの値が数値となっていました。なにがおかしいんだと思いながらactiverecord-mysql2spatial-adapter-42のドキュメントを再読…
すると、db設定のadapterを「mysql2」ではなく「mysql2spatial」にするという記述があったため変更してgeometry型の値を再度取得。
$ rails c
Loading development environment (Rails 4.2.5)
irb(main):001:0> l = Location.first
Location Load (0.2ms) SELECT `locations`.* FROM `locations` ORDER BY `locations`.`id` ASC LIMIT 1
skip_logging (1.7ms) SHOW FIELDS FROM `locations`
=> #Location id: 1, geom: #RGeo::Geos::CAPIPointImpl:0x3fd68132ac34 "POINT (138.48486379999997 35.0239507)"
irb(main):002:0> l.geom.class
=> RGeo::Geos::CAPIPointImpl
irb(main):003:0> l.geom.x
=> 138.48486379999997
irb(main):004:0> l.geom.y
=> 35.0239507
見事geometry型の値を取得することに成功しました！
ちなみに、データについてはspatial_adapterのgem使用時に登録しておいたデータでも問題なくgeometry型の値を取得できましたが、どうやらspatial_adapterのバージョンが低いとそのままでは使用できず、sql文でgeometryからxy値を取得して変換をしないとエラーとなるようです。
まとめ
Railsのgemは便利なものが多く、一度環境さえ作成できればかなり簡単に開発が行えるのですが、Ruby、Railsのバージョンを上げ、使ってたgemが使えなくなった際、どのgemが使えなくなったのか原因調査が難しく、代わりを見つける、または、自作しなければならないということになり、結構難易度が高いなーっと改めて実感しました。
gem周りについては、とにかく経験を積むしかないと思うので、また同じようなことがあれば情報共有ということで書いていければと思います。
では、今回はこの辺りで！
[Rails] テーブル無しのモデルでお問い合わせフォームをつくる（その1？）
2015年12月31日
望月です。皆さん、年末いかがお過ごしでしょうか。
入社して2年目の後半になり、なにか新しいことを・・・ということで、最近少しRailsをかきはじめました。
勉強のためにまずお問い合わせフォームを制作してみているので、それについてまとめておこうと思います。
(phpを業務で書きはじめた時、お問い合わせフォームを量産して修行をしたことを思い出します。。)
今回は、テーブルと関連づかないモデルを使ってお問い合わせフォームをつくります。
■参考
Ruby on Rails ガイド：体系的に Rails を学ぼう (Rails 4.2 対応)
http://railsguides.jp/
たのしいRuby 第4版 高橋 征義
http://www.amazon.co.jp/dp/4797372273/ref=cm_sw_r_tw_dp_Qy.Gwb0M63YMR
こんな記事もありました。
PHPとRubyを徹底比較！開発効率をあげて収益を増やす
http://techracho.bpsinc.jp/piichan1031/2013_05_13/8578
メリット・デメリット等もそうですが、記述もだいぶ違っていて驚いています。
（文のおわりに ; がいらなかったり、関数をかくときに括弧を省略できたり、returnを省略できたりetc.）
・3画面
入力画面（エラー画面）/ 確認画面 / 完了画面
・入力フォームは4つ（入力チェックを行う）
お名前【必須】/ 電話番号 / メールアドレス【必須】/ お問い合わせ内容【必須】
・入力エラーは各項目の下に表示する
※これ、実はあとで変更します
以上の仕様で制作開始です。
ビュー
上記では項目が「お名前」のみですが、とりあえずこんな感じで記述しました。
モデル
通常Railsではテーブルを関連づけたモデルをつくることで、validationなどをActiveRecordの機能を用いて実装できるので便利です。
しかし今回のお問い合わせフォームのようにテーブルはいらないけど、validationを自分で実装したくない・・・という場合などに、ActiveModelを使うことでテーブル無しのモデルをつくり、ActiveRecordのvalidation機能を使うことができます。
ちなみにActiveModelを使えるのはrails4からみたいです。
〜rails3の場合は、Activeattrというgemを使用して実装できるようなので、こちらを参考にしてみてください。
コントローラー
テーブルに関連づいているモデルの場合saveのタイミングでvalidationが実行されますが、今回はインスタンス生成の際に値をセットし、valid?で実行させます。
ja.ymlの記述もその他のモデルとは異なり、activerecordではなくactivemodelとして記述します。
わたしはactiverecord側に書いてしまっていて、エラーメッセージに項目名がでてこなくてしばらく困りました・・・
validationでエラー画面へ遷移した際、エラー文を@contacts.errors.messagesで取得しようと考えたのですがこれでは項目名が表示されない。
@contacts.errors.full_messagesで取得すると、項目名まで全部表示されますが、エラーメッセージのみの配列なので各項目の下に表示するのが難しい。
ということで、エラー文はフォームの上部にまとめて表示するように、一旦使用を変更・・・。
良い実装方法を知っている方がいましたら教えてください。
(railsのバージョンが上がれば対処法が見つかるかも・・・？)
ということで、お問い合わせフォーム、validationを通してエラー画面と確認画面に値を表示するところまで制作しました。
残りとしてはざっくり
・確認画面に[入力画面へ戻る]ボタンをつくる
・確認画面に[送信]ボタンをつくり、完了画面でお問い合わせ内容をメール送信する
値の保持には、flashを使おうと思ったのですが、fuelと違って配列を渡すことができないのですね。
年末年始の休暇中に調べながら完成させます。
今は、はじめたばかりで手探りで進んでいる状態ですが・・・来年にはrubyバリバリかけるようになりたいですね。
2016年は入社3年目に突入します。
もっと新しいことに挑戦して、技術力向上の年にしたいと思います。
それでは良いお年を！
入社して2年目の後半になり、なにか新しいことを・・・ということで、最近少しRailsをかきはじめました。
勉強のためにまずお問い合わせフォームを制作してみているので、それについてまとめておこうと思います。
(phpを業務で書きはじめた時、お問い合わせフォームを量産して修行をしたことを思い出します。。)
今回は、テーブルと関連づかないモデルを使ってお問い合わせフォームをつくります。
■参考
Ruby on Rails ガイド：体系的に Rails を学ぼう (Rails 4.2 対応)
http://railsguides.jp/
たのしいRuby 第4版 高橋 征義
http://www.amazon.co.jp/dp/4797372273/ref=cm_sw_r_tw_dp_Qy.Gwb0M63YMR
こんな記事もありました。
PHPとRubyを徹底比較！開発効率をあげて収益を増やす
http://techracho.bpsinc.jp/piichan1031/2013_05_13/8578
メリット・デメリット等もそうですが、記述もだいぶ違っていて驚いています。
（文のおわりに ; がいらなかったり、関数をかくときに括弧を省略できたり、returnを省略できたりetc.）
お問い合わせフォームの仕様
・3画面
入力画面（エラー画面）/ 確認画面 / 完了画面
・入力フォームは4つ（入力チェックを行う）
お名前【必須】/ 電話番号 / メールアドレス【必須】/ お問い合わせ内容【必須】
・入力エラーは各項目の下に表示する
※これ、実はあとで変更します
以上の仕様で制作開始です。
フォームの実装
ビュー
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <div class="sky-form" role="form"> | |
| <%= form_for :contacts, url: contacts_path do |f| %> | |
| <fieldset> | |
| <section> | |
| <label class="label"> | |
| <%= f.label :name, 'お名前' %> | |
| </label> | |
| <label class="input state-success"> | |
| <%= f.text_field :name %> | |
| </label> | |
| </section> | |
| <%= f.submit '確認画面へ' %> | |
| </fieldset> | |
| <% end %> | |
| </div> |
上記では項目が「お名前」のみですが、とりあえずこんな感じで記述しました。
モデル
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| class Contact | |
| include ActiveModel::Model | |
| attr_accessor :name, :tel, :email, :content | |
| # バリデーション設定 | |
| validates :name, presence: true | |
| validates :tel, presence: false, numericality: true | |
| validates :email, presence: true | |
| validates :content, presence: true | |
| end |
通常Railsではテーブルを関連づけたモデルをつくることで、validationなどをActiveRecordの機能を用いて実装できるので便利です。
しかし今回のお問い合わせフォームのようにテーブルはいらないけど、validationを自分で実装したくない・・・という場合などに、ActiveModelを使うことでテーブル無しのモデルをつくり、ActiveRecordのvalidation機能を使うことができます。
ちなみにActiveModelを使えるのはrails4からみたいです。
〜rails3の場合は、Activeattrというgemを使用して実装できるようなので、こちらを参考にしてみてください。
コントローラー
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| class ContactsController < ApplicationController | |
| def index | |
| @contacts = Contact.new | |
| end | |
| def confirm | |
| input_contact = contact_params | |
| @contacts = Contact.new(input_contact) | |
| if !@contacts.valid? | |
| render 'index' | |
| else | |
| @contacts = input_contact | |
| end | |
| end | |
| private | |
| def contact_params | |
| params.require(:contacts).permit(:name, :tel, :email, :content, :confirm) | |
| end | |
| end |
テーブルに関連づいているモデルの場合saveのタイミングでvalidationが実行されますが、今回はインスタンス生成の際に値をセットし、valid?で実行させます。
ja.ymlの記述もその他のモデルとは異なり、activerecordではなくactivemodelとして記述します。
わたしはactiverecord側に書いてしまっていて、エラーメッセージに項目名がでてこなくてしばらく困りました・・・
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| activemodel: | |
| models: | |
| contact: お問い合わせ | |
| attributes: | |
| contact: | |
| name: お名前 | |
| tel: 電話番号 | |
| email: メールアドレス | |
| content: お問い合わせ内容 |
エラー文を各項目の下に表示できない・・・
validationでエラー画面へ遷移した際、エラー文を@contacts.errors.messagesで取得しようと考えたのですがこれでは項目名が表示されない。
@contacts.errors.full_messagesで取得すると、項目名まで全部表示されますが、エラーメッセージのみの配列なので各項目の下に表示するのが難しい。
ということで、エラー文はフォームの上部にまとめて表示するように、一旦使用を変更・・・。
良い実装方法を知っている方がいましたら教えてください。
(railsのバージョンが上がれば対処法が見つかるかも・・・？)
まとめ・積み残し
ということで、お問い合わせフォーム、validationを通してエラー画面と確認画面に値を表示するところまで制作しました。
残りとしてはざっくり
・確認画面に[入力画面へ戻る]ボタンをつくる
・確認画面に[送信]ボタンをつくり、完了画面でお問い合わせ内容をメール送信する
値の保持には、flashを使おうと思ったのですが、fuelと違って配列を渡すことができないのですね。
年末年始の休暇中に調べながら完成させます。
今は、はじめたばかりで手探りで進んでいる状態ですが・・・来年にはrubyバリバリかけるようになりたいですね。
2016年は入社3年目に突入します。
もっと新しいことに挑戦して、技術力向上の年にしたいと思います。
それでは良いお年を！
憧れの月額課金サービスモデル（レビュー）。
2015年12月04日
こんにちは。システムエンジニアのとおやまです。
タイトルの件。安定の月額課金。憧れます。人々は、どんなものにお金を（定期的に！）支払っているのでしょうか。みなさん自身はいかがですか？
私が今年利用したものを10個。
１）Apple Music（もうやめた）
２）AWA（無料期間のみ）
３）LINE Music（無料期間のみ）
４）Dropbox
５）Cookpad
６）マンガボックス
７）Feedbin（Feedlyに切り替えてやめた）
８）MindMister（使わないのでやめた）
９）Netflix
10）SUSTINA
ほんとはHeroku有料で使ってますとかですとかっこいいなと思いますが…。
このままでは月額課金貧困になってしまいます…。音楽関係の代替はYoutube と Musictonicですが他に良いのがありましたら教えてください。
さてさて。上記サービスの中でも、みなさんがあまり使わないだろうなーと思う、ファッションレンタルアプリ「SUSTINA」を今回はご紹介したいと思います。
月額5,800円。１回で５着まで借りられ、返却期限なしです。
人気のため、申し込み後から入会までかなり待たされるようです。私は６月に申し込んで、９月末に入れました。
現在借りている服は、この５着です・・・。
借りると、こんな感じで届きます。
ビニールに入ってるんですが気にせずどんどん開封して大丈夫みたいです。
返すときは、同梱されている返送用伝票を書いて、佐川急便さんに電話で回収をお願いてしまえばOK。
洗濯も自分の服と一緒で大丈夫とのこと。送られてきたときのビニールはとっておいて、返送時に入れて梱包するのがいいかなぁと思います。
そもそも古着がダメという方は利用できそうにないですが、それが大丈夫なら、「ときめき」断捨離が流行する昨今ですし、試してみるのも一興です。写真だけで洋服を選ぶ難しさは、他の通販も同じ。レンタル戻しのタイミングさえ見逃さなければ、ハイブランドなあれやApple Watchなんかも借りられます。
今年は代官山コレクションの衣装協力など、面白い取り組みもされているようで。これからもレンタルできる洋服をどんどん増やして頑張って欲しいなぁ。
来年楽しみなウェブサービス（おそらく月額）は、YouTubeRedと、カクヨム。
2016年は、”試してみる＋わたしも作ってみる！” 年にしたいなと思っています。
ーーーーーー
最近OPENした「痛快！静岡県」をよろしくお願いします！ボケてください！！
womo12月号、発行しました！クリスマスバーションのロゴがかわいいwomoネットもご覧ください。
ーーーーーー
タイトルの件。安定の月額課金。憧れます。人々は、どんなものにお金を（定期的に！）支払っているのでしょうか。みなさん自身はいかがですか？
私が今年利用したものを10個。
１）Apple Music（もうやめた）
２）AWA（無料期間のみ）
３）LINE Music（無料期間のみ）
４）Dropbox
５）Cookpad
６）マンガボックス
７）Feedbin（Feedlyに切り替えてやめた）
８）MindMister（使わないのでやめた）
９）Netflix
10）SUSTINA
ほんとはHeroku有料で使ってますとかですとかっこいいなと思いますが…。
このままでは月額課金貧困になってしまいます…。音楽関係の代替はYoutube と Musictonicですが他に良いのがありましたら教えてください。
さてさて。上記サービスの中でも、みなさんがあまり使わないだろうなーと思う、ファッションレンタルアプリ「SUSTINA」を今回はご紹介したいと思います。
月額5,800円。１回で５着まで借りられ、返却期限なしです。
人気のため、申し込み後から入会までかなり待たされるようです。私は６月に申し込んで、９月末に入れました。
現在借りている服は、この５着です・・・。
借りると、こんな感じで届きます。
ビニールに入ってるんですが気にせずどんどん開封して大丈夫みたいです。
返すときは、同梱されている返送用伝票を書いて、佐川急便さんに電話で回収をお願いてしまえばOK。
洗濯も自分の服と一緒で大丈夫とのこと。送られてきたときのビニールはとっておいて、返送時に入れて梱包するのがいいかなぁと思います。
そもそも古着がダメという方は利用できそうにないですが、それが大丈夫なら、「ときめき」断捨離が流行する昨今ですし、試してみるのも一興です。写真だけで洋服を選ぶ難しさは、他の通販も同じ。レンタル戻しのタイミングさえ見逃さなければ、ハイブランドなあれやApple Watchなんかも借りられます。
今年は代官山コレクションの衣装協力など、面白い取り組みもされているようで。これからもレンタルできる洋服をどんどん増やして頑張って欲しいなぁ。
来年楽しみなウェブサービス（おそらく月額）は、YouTubeRedと、カクヨム。
2016年は、”試してみる＋わたしも作ってみる！” 年にしたいなと思っています。
ーーーーーー
最近OPENした「痛快！静岡県」をよろしくお願いします！ボケてください！！
womo12月号、発行しました！クリスマスバーションのロゴがかわいいwomoネットもご覧ください。
ーーーーーー
非デザイナーでも困らない！Bootstrapのページが誰でも簡単につくれるジェネレーター5つ
2015年07月13日
先週雨続きで、どんよりした気分だったもちづきです。
そんな天気で外出する気が起きなかったので良い機会だと思い
Bootstrapを触っていました。
…ということで(？)今回は、誰でも簡単にBootstrapページをつくれてしまうジェネレーターを
メモもかねて簡単にまとめました。
ドラッグ&ドロップでグリッドやコンポーネントを配置でき、Webページを簡単に作れます
■jetstrap
・会員登録が必要。有料だが、基本機能は無料でも使える
※無料では1プロジェクト3画面までつくれる
・１画面で編集とプレビュー(複数デバイスの表示)をいつでも切り替えできる
複数画面作れるところが便利
■Layoutit
・ソースをダウンロードするには、会員登録が必要
・カラムを自分で指定して自由に作れる
・コンポーネントを配置したあとスタイルの変更が可能
■Lolytin
・会員登録は不要
・コンポーネントが視覚的にわかりやすい
1ページのサイトに向いているかも
■pingendo
・会員登録は不要
・オンラインではなく、ダウンロードしてローカルで作業できる Mac / Windows / Linux版あり
■http://shoelace.io
・ページ全体ではなく、グリッドのみ
・会員登録は不要
・スマホ、タブレット、PC等、各デバイスでの見え方を確認しながらつくれる
・カラムをクリック＆ドラックで作成する
■Honoka
・日本語も美しく表示できるBootstrapテーマ
・ラ○ライブ好きにはらまたないですね。Honoka
■http://purecss.io
・Bootsrtapではなく、CSSだけでレスポンシブデザインを実装できる
・Bootstrapよりも軽量
ジェネレーターを使えば、htmlやcssの知識がなくてもだれでも簡単にサイトがつくれてしまいます。
ちょっとしたページやモックの作成に使うと、制作時間短縮ができ便利かと思います。
加えて、Bootstrapの参考書としては下記のものを使っています。
いくつか見た中でもわかりやすいので、気になる方はもちづきにお声掛け下さい〜貸し出しします！
それでは、梅雨明けまで皆さん頑張りましょう！
そんな天気で外出する気が起きなかったので良い機会だと思い
Bootstrapを触っていました。
…ということで(？)今回は、誰でも簡単にBootstrapページをつくれてしまうジェネレーターを
メモもかねて簡単にまとめました。
Bootstrapページを作成できるジェネレーター5つ
ドラッグ&ドロップでグリッドやコンポーネントを配置でき、Webページを簡単に作れます
■jetstrap
・会員登録が必要。有料だが、基本機能は無料でも使える
※無料では1プロジェクト3画面までつくれる
・１画面で編集とプレビュー(複数デバイスの表示)をいつでも切り替えできる
複数画面作れるところが便利
■Layoutit
・ソースをダウンロードするには、会員登録が必要
・カラムを自分で指定して自由に作れる
・コンポーネントを配置したあとスタイルの変更が可能
■Lolytin
・会員登録は不要
・コンポーネントが視覚的にわかりやすい
1ページのサイトに向いているかも
■pingendo
・会員登録は不要
・オンラインではなく、ダウンロードしてローカルで作業できる Mac / Windows / Linux版あり
■http://shoelace.io
・ページ全体ではなく、グリッドのみ
・会員登録は不要
・スマホ、タブレット、PC等、各デバイスでの見え方を確認しながらつくれる
・カラムをクリック＆ドラックで作成する
おまけ
■Honoka
・日本語も美しく表示できるBootstrapテーマ
・ラ○ライブ好きにはらまたないですね。Honoka
■http://purecss.io
・Bootsrtapではなく、CSSだけでレスポンシブデザインを実装できる
・Bootstrapよりも軽量
さいごに
ジェネレーターを使えば、htmlやcssの知識がなくてもだれでも簡単にサイトがつくれてしまいます。
ちょっとしたページやモックの作成に使うと、制作時間短縮ができ便利かと思います。
加えて、Bootstrapの参考書としては下記のものを使っています。
いくつか見た中でもわかりやすいので、気になる方はもちづきにお声掛け下さい〜貸し出しします！
それでは、梅雨明けまで皆さん頑張りましょう！
AWS summit Tokyo 2015に行ってきました！
2015年06月10日
今回はタイトル通り、社内でも使用しているAWSの知識を深めるため、
AWS summit Tokyo 2015へ行ってきました！
自分が参加したのは1dayになりますが、
そこで参加したセッションで割りと聞いたAWSのサービスが以下となります。
Amazon Kinesis
Amazon Cognito
Amazon RedShift
AWS Lambda
Amazon DynamoDB
Amazon S3
AWS Identity and Access Management（IAM）
この中で実際の業務につかっているのは、S3のみとなりますが。。。
ビッグデータの取り扱い、セキュリティの部分で、
上記サービスを組み合わせて、導入しているという事例が多く紹介されていました。
今後のWEB開発で、社内で絶対にやらないとならないと言われているのが、
データの可視化ですが、上記サービスのKinesis、Redshift、S3、
あと、今回のサミット時に新たに紹介されたAmazon Machine Learningを使うことで、
自分で開発を行わなくてもほぼほぼできてしまうのでないかと思います。
Amazon Machine Learningについては、
機械学習を２人のスペシャリストが１ヶ月近くかけて行った結果と、
機械学習に縁のないエンジニアが５日間、awsの機械学習のサービスを利用して生み出された結果が
同じになったという話もあり、専門知識がなくても手軽に利用できるとのこと。
各サービスについては、現状では正直正しく伝えられる気がしないので、
実際に業務で使った際に、紹介されていただきたいと思います。
所々でagility Speedという単語がかなり言われており、いろいろ考える前に早く動け、
AWSには早く動くためのサービスがあるから、使ってねっと言われてるような気がしました。
確かに、ほぼWEB開発に必要なものはほとんどAWSのサービス内に用意されているので、
用意されているものは、自分たちで開発せず使って早く開発する。
そうすることで余分な部分に時間を掛けず、試行回数を増やせるようにしないと、
当たるサービスというのは生まれないのだと確信しました。
とにかく、考える前に手を動かすようにする癖をつけていきます！
AWS summit Tokyo 2015へ行ってきました！
自分が参加したのは1dayになりますが、
そこで参加したセッションで割りと聞いたAWSのサービスが以下となります。
Amazon Kinesis
Amazon Cognito
Amazon RedShift
AWS Lambda
Amazon DynamoDB
Amazon S3
AWS Identity and Access Management（IAM）
この中で実際の業務につかっているのは、S3のみとなりますが。。。
ビッグデータの取り扱い、セキュリティの部分で、
上記サービスを組み合わせて、導入しているという事例が多く紹介されていました。
今後のWEB開発で、社内で絶対にやらないとならないと言われているのが、
データの可視化ですが、上記サービスのKinesis、Redshift、S3、
あと、今回のサミット時に新たに紹介されたAmazon Machine Learningを使うことで、
自分で開発を行わなくてもほぼほぼできてしまうのでないかと思います。
Amazon Machine Learningについては、
機械学習を２人のスペシャリストが１ヶ月近くかけて行った結果と、
機械学習に縁のないエンジニアが５日間、awsの機械学習のサービスを利用して生み出された結果が
同じになったという話もあり、専門知識がなくても手軽に利用できるとのこと。
各サービスについては、現状では正直正しく伝えられる気がしないので、
実際に業務で使った際に、紹介されていただきたいと思います。
まとめ
所々でagility Speedという単語がかなり言われており、いろいろ考える前に早く動け、
AWSには早く動くためのサービスがあるから、使ってねっと言われてるような気がしました。
確かに、ほぼWEB開発に必要なものはほとんどAWSのサービス内に用意されているので、
用意されているものは、自分たちで開発せず使って早く開発する。
そうすることで余分な部分に時間を掛けず、試行回数を増やせるようにしないと、
当たるサービスというのは生まれないのだと確信しました。
とにかく、考える前に手を動かすようにする癖をつけていきます！
フロントエンドエンジニアを目指して
2015年03月23日
ここ数年Web開発に関わってきてシステムの開発だけでは生きていけないと実感し、
やっとマークアップの作業にも手を出し始めました今日このごろです。
タイトルの通り、フロントエンドエンジニアを目指してということで、
デザインチームの勉強会に混じりWEBフォントの自作を行ってみました。
皆さんは、gulpというタスク自動化ツールをご存知でしょうか？
自分も勉強会に出るまで名前すらしならなかったのですが、
少し調べてみるとCSS、JSファイルの圧縮、結合、Sassのコンパイル、AWSのS3へのファイルアップロード
など、タスクを自分で組めばかなり色々なことができるようです。
今回はそのgulpを使ってWEBフォントを作成するということで、
gulp導入までをとりあえず備忘録として書いていきたいと思います。
手順としては、
Homebrewのインストール＞nodebrewのインストール＞gulpのインストール
となります。
あ、ちなみに導入についてはMacが前提となりますので。。。
Windowsの方はそっと閉じて下さい。
Homebrewとは、なんぞやっという話になると思うのですが、
簡単に言うと、コマンド一発でソフトウェアのインストール、アンインストールができるものっと思っていただければOKだと思います。
では早速、Homebrewのインストールですが、
Homebrew 公式サイトに書かれているように以下のコマンドをterminalで入力+EnterしていただければOKです。
Xcodeをインストールしている方は、何事もなくインストールが完了すると思いますが、
インストールしていない方はCommand Line Toolsのインストール等を求められますので、インストールしてください。
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
インストール後、以下のメッセージが表示されれば完了です。
==> Installation successful!
You should run `brew doctor' *before* you install anything.
上記のインストール作業が完了後、以下のコマンドをterminalで実行してください。
brew doctor
Warning等が表示されていなければ、Homebrewのインストールは完了です。
nodebrewですが、node.jsを自分のマシン内でバージョン管理するためのツールです。
node.jsを普通にインストールするでも全然構いませんが、nodebrewをインストールしておけば、バージョンの切り替えが簡単に行えてかなり便利です。
nodebrewのインストールは、homebrewを使ってインストールしますので、
上記のhomebrewのインストールを行っていることを前提とします。
まずはhomebrewでnodebrewがインストール可能かを確認するため、
以下のコマンドをterminalで実行してください。
「No formula found for ...」等のメッセージが表示されず、「nodebrew」と表示されればインストール可能です。
brew search nodebrew
では、次にインストールですが、以下のコマンドをterminalで実行してください。
brew install nodebrew
最後にインストールを確認するために、以下のコマンドをterminalで実行してください。
nodebrewのバージョンが表示されれば、無事インストール完了となります。
nodebrew
nodebrewでインストールするnode.jsにパスを通す必要があるため、
「~/.bash_profile」ファイルに以下の内容を追記して、「source ~/.bash_profile」をterminalで実行してください。
export PATH=$HOME/.nodebrew/current/bin:$PATH
.bash_profileはFinderからはそのままだと確認できないため、
terminalで「vi ~/.bash_profile」を実行してもらい、編集するのが楽だと思います。
viについては、通常のテキストエディタと編集の仕方が異なりますので、「vi linux」等で調べてください！
nodebrewを使用して、node.jsをインストールします。
以下のコマンドをterminalで実行してください。
nodebrew install-binary "version" version部分は自分がインストールしたいversionに置き換えてください
今回使用したバージョンはv0.10.36なので、「nodebrew install-binary v0.10.36」となります。
以下のコマンドをterminalで実行すると、nodebrewでインストールしたnode.jsの一覧が表示されます。
currentについては、現状使用しているnode.jsのバージョンのため、何も設定していない場合は「none」と表示されます。
nodebrew list
nodebrewでインストールしたnode.jsの一覧から、使用するnode.jsを指定するために、
以下のコマンドをterminalで実行するします。
nodebrew use "version" version部分は自分がインストールしたいversionに置き換えてください
最後に以下のコマンドをterminalで実行し、自分が指定したバージョンが表示されれば、
nodebrewのインストール、設定が完了となります。
node -v
ここで、Errorが出る場合は、パスを通すことに失敗している場合が多いので、
「~/.bash_profile」の内容確認、または、「source ~/.bash_profile」を実行をしてみてください。
gulpの説明については、上記で説明しているので割愛させていただきます！
以下のコマンドをterminalで実行するだけで完了です。
npm install -g gulp
これでWarning等が表示されなければインストール完了です。
今回インストールしたものはすべてterminalからコマンドを打って行いました。
システムに関わっている人にとっては、簡単だとは思いますが、デザイナーの方には取ってはかなりハードルものとなりますので、助けになれば幸いです。
次回はインストールしたgulpの設定、タスクの作成について書いていきたいと思います！
やっとマークアップの作業にも手を出し始めました今日このごろです。
タイトルの通り、フロントエンドエンジニアを目指してということで、
デザインチームの勉強会に混じりWEBフォントの自作を行ってみました。
皆さんは、gulpというタスク自動化ツールをご存知でしょうか？
自分も勉強会に出るまで名前すらしならなかったのですが、
少し調べてみるとCSS、JSファイルの圧縮、結合、Sassのコンパイル、AWSのS3へのファイルアップロード
など、タスクを自分で組めばかなり色々なことができるようです。
今回はそのgulpを使ってWEBフォントを作成するということで、
gulp導入までをとりあえず備忘録として書いていきたいと思います。
手順としては、
Homebrewのインストール＞nodebrewのインストール＞gulpのインストール
となります。
あ、ちなみに導入についてはMacが前提となりますので。。。
Windowsの方はそっと閉じて下さい。
Homebrew
Homebrewとは、なんぞやっという話になると思うのですが、
簡単に言うと、コマンド一発でソフトウェアのインストール、アンインストールができるものっと思っていただければOKだと思います。
Homebrewのインストール
では早速、Homebrewのインストールですが、
Homebrew 公式サイトに書かれているように以下のコマンドをterminalで入力+EnterしていただければOKです。
Xcodeをインストールしている方は、何事もなくインストールが完了すると思いますが、
インストールしていない方はCommand Line Toolsのインストール等を求められますので、インストールしてください。
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
インストール後、以下のメッセージが表示されれば完了です。
==> Installation successful!
You should run `brew doctor' *before* you install anything.
Homebrewのインストール確認
上記のインストール作業が完了後、以下のコマンドをterminalで実行してください。
brew doctor
Warning等が表示されていなければ、Homebrewのインストールは完了です。
nodebrew
nodebrewですが、node.jsを自分のマシン内でバージョン管理するためのツールです。
node.jsを普通にインストールするでも全然構いませんが、nodebrewをインストールしておけば、バージョンの切り替えが簡単に行えてかなり便利です。
nodebrewのインストール
nodebrewのインストールは、homebrewを使ってインストールしますので、
上記のhomebrewのインストールを行っていることを前提とします。
まずはhomebrewでnodebrewがインストール可能かを確認するため、
以下のコマンドをterminalで実行してください。
「No formula found for ...」等のメッセージが表示されず、「nodebrew」と表示されればインストール可能です。
brew search nodebrew
では、次にインストールですが、以下のコマンドをterminalで実行してください。
brew install nodebrew
最後にインストールを確認するために、以下のコマンドをterminalで実行してください。
nodebrewのバージョンが表示されれば、無事インストール完了となります。
nodebrew
nodebrewのパスを通す
nodebrewでインストールするnode.jsにパスを通す必要があるため、
「~/.bash_profile」ファイルに以下の内容を追記して、「source ~/.bash_profile」をterminalで実行してください。
export PATH=$HOME/.nodebrew/current/bin:$PATH
.bash_profileはFinderからはそのままだと確認できないため、
terminalで「vi ~/.bash_profile」を実行してもらい、編集するのが楽だと思います。
viについては、通常のテキストエディタと編集の仕方が異なりますので、「vi linux」等で調べてください！
node.jsをインストール
nodebrewを使用して、node.jsをインストールします。
以下のコマンドをterminalで実行してください。
nodebrew install-binary "version" version部分は自分がインストールしたいversionに置き換えてください
今回使用したバージョンはv0.10.36なので、「nodebrew install-binary v0.10.36」となります。
node.jsの指定
以下のコマンドをterminalで実行すると、nodebrewでインストールしたnode.jsの一覧が表示されます。
currentについては、現状使用しているnode.jsのバージョンのため、何も設定していない場合は「none」と表示されます。
nodebrew list
nodebrewでインストールしたnode.jsの一覧から、使用するnode.jsを指定するために、
以下のコマンドをterminalで実行するします。
nodebrew use "version" version部分は自分がインストールしたいversionに置き換えてください
最後に以下のコマンドをterminalで実行し、自分が指定したバージョンが表示されれば、
nodebrewのインストール、設定が完了となります。
node -v
ここで、Errorが出る場合は、パスを通すことに失敗している場合が多いので、
「~/.bash_profile」の内容確認、または、「source ~/.bash_profile」を実行をしてみてください。
gulp
gulpの説明については、上記で説明しているので割愛させていただきます！
gulpのインストール
以下のコマンドをterminalで実行するだけで完了です。
npm install -g gulp
これでWarning等が表示されなければインストール完了です。
まとめ
今回インストールしたものはすべてterminalからコマンドを打って行いました。
システムに関わっている人にとっては、簡単だとは思いますが、デザイナーの方には取ってはかなりハードルものとなりますので、助けになれば幸いです。
次回はインストールしたgulpの設定、タスクの作成について書いていきたいと思います！
(続) システム開発の工程について
2014年09月08日
さっそく本題に入っていきます。
システム開発の工程について、もうちょっと自分の考えを書いていきたいと思います。
まずは、システム開発時に私が現状やりやすいなーっと思っている工程から。
【開発工程①】
01.要件定義
02.外部設計（概要設計）
03.内部設計（詳細設計）
04.テストケース作成
05.コーディング
06.テスト
07.リリース
前回書いた工程とほぼ変わりはないのですが、テストを一纏めにし、結合テストと総合テストをまとめた内容を行います。
単体テストを除いた理由としては、デザインとシステムが密接に関わるため、システム側のみの単体テストの意味があまりないからです。
また、結合テストと総合テストをまとめた理由としては、基本的には画面の表示、操作のテストとなり、結合テストと総合テストで内容の差があまりないためです。
基本的には設計を重視し、それ以外の工数を削減するというシステム開発の工程です。
テストについては現状手動でやっていますが、いろいろ調べてみるとテストを自動化するツールが結構あるので、
単純な部分はツール、複雑な部分は手動で行うようにして、できる限り手動でやる部分を少なくすることで、
ミスや工数の削減につながるのではないかと思います。
次に、個人的にはこれができたら一番いいんじゃないかなと思う工程です。
【開発工程②】
1.要件定義
2.コーディング
3.リリース
要件定義後、実際にコーディングをしてしまう方法です。
設計書などの文章ではなく、実際動くものを作っていくので、お客様は作っているもののイメージがしやすく、
設計書、テストケース作成などの工数をすべてコーディングにまわせるので、システムの作りこみに専念できると思います。
また、この方法での最大のメリットは、動くものをどんどん作っていくので、SEが主導となって開発ができる点です。
この方法については、かなりメリットが多いのですが、
その分、全体像を把握した上で、動くものをどんどん作っていかないとならないので、SEとしての高い技術が要求されます。
ざっくりと二通りの工程を書いてみましたが、もちろん他にもいろいろなシステム開発の工程はあります。
正直、どれが正解でどれが間違いかはなく、ユーザの要求、開発規模等に合わせ臨機応変に変えていくのがベストではないかと思います。
そのためには、現状の開発工程がやりやすいからと固執せず、まず様々なシステム開発の工程を経験した上で、メリット、デメリットを把握し、使い分けられるようにしていかなけれいけません。
ということで、次の開発では開発工程から考えてシステム開発を行っていきたいと思います。
システム開発の工程について、もうちょっと自分の考えを書いていきたいと思います。
まずは、システム開発時に私が現状やりやすいなーっと思っている工程から。
【開発工程①】
01.要件定義
02.外部設計（概要設計）
03.内部設計（詳細設計）
04.テストケース作成
05.コーディング
06.テスト
07.リリース
前回書いた工程とほぼ変わりはないのですが、テストを一纏めにし、結合テストと総合テストをまとめた内容を行います。
単体テストを除いた理由としては、デザインとシステムが密接に関わるため、システム側のみの単体テストの意味があまりないからです。
また、結合テストと総合テストをまとめた理由としては、基本的には画面の表示、操作のテストとなり、結合テストと総合テストで内容の差があまりないためです。
基本的には設計を重視し、それ以外の工数を削減するというシステム開発の工程です。
テストについては現状手動でやっていますが、いろいろ調べてみるとテストを自動化するツールが結構あるので、
単純な部分はツール、複雑な部分は手動で行うようにして、できる限り手動でやる部分を少なくすることで、
ミスや工数の削減につながるのではないかと思います。
次に、個人的にはこれができたら一番いいんじゃないかなと思う工程です。
【開発工程②】
1.要件定義
2.コーディング
3.リリース
要件定義後、実際にコーディングをしてしまう方法です。
設計書などの文章ではなく、実際動くものを作っていくので、お客様は作っているもののイメージがしやすく、
設計書、テストケース作成などの工数をすべてコーディングにまわせるので、システムの作りこみに専念できると思います。
また、この方法での最大のメリットは、動くものをどんどん作っていくので、SEが主導となって開発ができる点です。
この方法については、かなりメリットが多いのですが、
その分、全体像を把握した上で、動くものをどんどん作っていかないとならないので、SEとしての高い技術が要求されます。
ざっくりと二通りの工程を書いてみましたが、もちろん他にもいろいろなシステム開発の工程はあります。
正直、どれが正解でどれが間違いかはなく、ユーザの要求、開発規模等に合わせ臨機応変に変えていくのがベストではないかと思います。
そのためには、現状の開発工程がやりやすいからと固執せず、まず様々なシステム開発の工程を経験した上で、メリット、デメリットを把握し、使い分けられるようにしていかなけれいけません。
ということで、次の開発では開発工程から考えてシステム開発を行っていきたいと思います。
SE的 最近の気になるニュース5選
2014年08月28日
暑い日が続きますが、みなさんはいかがお過ごしですか？
夏風邪の高山です。
弊社では、webサイト制作（SNSアプリなんかも）、スマフォアプリの制作なんかをしています。
言語は、webであれば、主にPHPを使って開発をしていますし、アプリであればobjective-cでの開発（swiftはまだ）ですね。
そんな自分が最近気になったニュース5選。
http://ascii.jp/elem/000/000/925/925838/
PHPが下火というのは、なんとなくそうなのかなと。
いまや、web系言語は数えきれないほどあって、一体何が自分たちの開発にとって最適（効率の良い）な言語とは何か、
どの言語を選択すべきか、非常に難しい状況です。
とあるベンチャー企業では、年に1度エンジニアが宿に数日篭って合宿を行い、流行りの言語を幾つか試し、自分達に最適な言語を選び直す事をするそうです。
これって、年に1度、自分達が開発する言語が変わるということですから、エンジニアにとってはかなり労力がいるし、それだけ移り変わりが早いということ。
エンジニアは大変だー。
http://www.itmedia.co.jp/mobile/articles/1408/25/news059.html
日本はどうなのか？と思いますが、実際、自分も業務としてアプリを探したり、ダウンロードしますが、
以前ほどしなくなりました。
固定のアプリで充分満足してしまっているし、元々入っているapple純正のアプリが使い勝手が良かったりするので、
余計にダウンロードしない。
少し前の、アプリバブルは完全に弾けたのかもしれません。
エンジニアは大変だー。
http://nge.jp/2014/08/22/post-3540
いや、コーディング不要にするための仕組みを、結局コーディングするのだから、世の中からコーディングは無くならないんですよね、実際のところ。
ただ、xcodeで開発すると分かるのですが、パーツを並べて、Viewを繋げていけば簡単なアプリは作れてしまうのですよね。
「appleは、コードを一切書かなくても、アプリを作れるようにしようとしている」と言っている人がいましたが、実際にそうなった場合、
エンジニアに求められるスキルは、今よりも更に高いものとなるのでしょうね。
エンジニアは大変だー。
http://saigaijyouhou.com/blog-entry-3598.html
結局、今回はペンギンアップデートは行われず、googleのテスト実施だったのでは無いか？と言われています。
本番でテストするなよ！って感じです。
結局、SEO対策をして、SEOに強いサイトにしても、googleの匙加減で如何様にでもなってしまうということ。
この辺、最近だとリブセンスが有名ですよね。（「リブセンス seo」で検索すると色々出てきますので、知らない人は見てみて下さい）
SEO強くしても、コンテンツがしっかりしてないと、意味ないということです、結局。
http://ja.ishibashihideto.net/blog/web-designer-survival/
この記事を見て思うのは、デザイナーとエンジニアの境界線が曖昧になりつつあるのは確かで、
少ない人数で開発することの多いweb開発では、むしろその方が開発スピードが早く、作業負荷分散としても良い。
デザイナーが不要といよりかは、エンジニア的な要素が、デザイナーにも必要とされているのだろうと言うことですね。
デザイナーも、エンジニアも大変だー。
結局、何が言いたいのかというと、どんどん変わってるんだよと。
社内や、日々の作業にのみ目を向けていると、あっという間に置いて行かれるよという、ありきたりなまとめ。
変化が著しいことは、飽きないとも言える。
デザイナーも、エンジニアも頑張りましょう！
夏風邪の高山です。
弊社では、webサイト制作（SNSアプリなんかも）、スマフォアプリの制作なんかをしています。
言語は、webであれば、主にPHPを使って開発をしていますし、アプリであればobjective-cでの開発（swiftはまだ）ですね。
そんな自分が最近気になったニュース5選。
●PHP、かつてWebで人気だった言語が下火になりつつある
http://ascii.jp/elem/000/000/925/925838/
PHPが下火というのは、なんとなくそうなのかなと。
いまや、web系言語は数えきれないほどあって、一体何が自分たちの開発にとって最適（効率の良い）な言語とは何か、
どの言語を選択すべきか、非常に難しい状況です。
とあるベンチャー企業では、年に1度エンジニアが宿に数日篭って合宿を行い、流行りの言語を幾つか試し、自分達に最適な言語を選び直す事をするそうです。
これって、年に1度、自分達が開発する言語が変わるということですから、エンジニアにとってはかなり労力がいるし、それだけ移り変わりが早いということ。
エンジニアは大変だー。
●モバイルユーザーの65％は最近アプリをダウンロードしていない──米comScore調べ
http://www.itmedia.co.jp/mobile/articles/1408/25/news059.html
日本はどうなのか？と思いますが、実際、自分も業務としてアプリを探したり、ダウンロードしますが、
以前ほどしなくなりました。
固定のアプリで充分満足してしまっているし、元々入っているapple純正のアプリが使い勝手が良かったりするので、
余計にダウンロードしない。
少し前の、アプリバブルは完全に弾けたのかもしれません。
エンジニアは大変だー。
●アプリ製作者は注意！コーディング不要で気軽に作れる時代が到来
http://nge.jp/2014/08/22/post-3540
いや、コーディング不要にするための仕組みを、結局コーディングするのだから、世の中からコーディングは無くならないんですよね、実際のところ。
ただ、xcodeで開発すると分かるのですが、パーツを並べて、Viewを繋げていけば簡単なアプリは作れてしまうのですよね。
「appleは、コードを一切書かなくても、アプリを作れるようにしようとしている」と言っている人がいましたが、実際にそうなった場合、
エンジニアに求められるスキルは、今よりも更に高いものとなるのでしょうね。
エンジニアは大変だー。
●グーグルで大変動発生中！ヤフーとグーグルで検索順位が激変！大規模なペンギンアップデートか？
http://saigaijyouhou.com/blog-entry-3598.html
結局、今回はペンギンアップデートは行われず、googleのテスト実施だったのでは無いか？と言われています。
本番でテストするなよ！って感じです。
結局、SEO対策をして、SEOに強いサイトにしても、googleの匙加減で如何様にでもなってしまうということ。
この辺、最近だとリブセンスが有名ですよね。（「リブセンス seo」で検索すると色々出てきますので、知らない人は見てみて下さい）
SEO強くしても、コンテンツがしっかりしてないと、意味ないということです、結局。
●ウェブサービス開発の現場におけるデザイナー不要論と5〜10年後の生存戦略
http://ja.ishibashihideto.net/blog/web-designer-survival/
この記事を見て思うのは、デザイナーとエンジニアの境界線が曖昧になりつつあるのは確かで、
少ない人数で開発することの多いweb開発では、むしろその方が開発スピードが早く、作業負荷分散としても良い。
デザイナーが不要といよりかは、エンジニア的な要素が、デザイナーにも必要とされているのだろうと言うことですね。
デザイナーも、エンジニアも大変だー。
まとめ
結局、何が言いたいのかというと、どんどん変わってるんだよと。
社内や、日々の作業にのみ目を向けていると、あっという間に置いて行かれるよという、ありきたりなまとめ。
変化が著しいことは、飽きないとも言える。
デザイナーも、エンジニアも頑張りましょう！
システム開発の工程ついて
2014年08月11日
凝った前置きを考えてみましたが、全然思いつかなったので、
さっそく本題に移りたいと思います。
っということで今回の本題はというと…
タイトル通り、システム開発の工程についてです。
みなさんはシステム開発と聞いたとき、簡単にどんな作業光景をイメージしますか？
私がこの業界に入る前にシステム開発と聞いたときイメージしたのは、一人で黙々とPCに向かい、コードを書いていくという作業光景です。
そのため、システム開発の大半はコードを書くことに費やされると思っていたのですが…大きな勘違いだったと思い知らされました。
私が最初に開発に携わったシステム開発をしたときに使われた手法は、ウォーターフォール・モデルというものです。
システム開発をいくつかの工程に分け、前工程が完了しない限り次工程に進まない、また、水が下から上に流れないように基本的には前工程への後戻りを行わないというかなり固いものでした。
もうすこし具体的にそのときの開発工程を以下に記載してみましたが、
見ていただくと分かる通り、コードを書く工程というのは、システム開発のごく一部となっています。
また、期間的にもかなり少なく、1年間の開発の中で、コーディングを行っていた期間は1ヶ月未満でした。
【開発工程】
01.要件定義
02.外部設計(概要設計)
03.内部設計(詳細設計)
04.単体テスト テストケース作成
05.結合テスト テストケース作成
06.総合テスト テストケース作成
07.コーディング
08.単体テスト
09.結合テスト
10.総合テスト
11.リリース
※私が実際に開発した際の工程であり、同様の手法を使用しても工程は会社やプロジェクトなどで異なります。
っというようにシステム開発≠コードを書くではないよということをわかっていただければ嬉しいです。
現状、上記と同じように開発をしているのかと言われると、答えは「NO」です。
説明が抜けてしまっていましたが、その当時開発していたシステムは、
かなり大規模な組み込み系のシステム開発となっており、開発メンバーも私が知る限りでも100人以上はいるようなものでした。
それをそのまま実行しようとすると、一つのWEBサイトを作成するのに何年もかけることになってしまいます。
もちろん、そんなことはできないため、取捨選択をして工程を簡略化した上で開発を行っています。
では、どの工程をどのようにして簡略すればいいのかっということになるのですが、
どれが正しくてどれが間違いなのか私の中でも整理できていません。
そのため、すこし中途半端になってしまいますが、今回はこのあたりとさせていただきたいと思います。
次回は、ある程度、私の中での考えをまとめて書きたいと思います。
さっそく本題に移りたいと思います。
っということで今回の本題はというと…
タイトル通り、システム開発の工程についてです。
みなさんはシステム開発と聞いたとき、簡単にどんな作業光景をイメージしますか？
私がこの業界に入る前にシステム開発と聞いたときイメージしたのは、一人で黙々とPCに向かい、コードを書いていくという作業光景です。
そのため、システム開発の大半はコードを書くことに費やされると思っていたのですが…大きな勘違いだったと思い知らされました。
私が最初に開発に携わったシステム開発をしたときに使われた手法は、ウォーターフォール・モデルというものです。
システム開発をいくつかの工程に分け、前工程が完了しない限り次工程に進まない、また、水が下から上に流れないように基本的には前工程への後戻りを行わないというかなり固いものでした。
もうすこし具体的にそのときの開発工程を以下に記載してみましたが、
見ていただくと分かる通り、コードを書く工程というのは、システム開発のごく一部となっています。
また、期間的にもかなり少なく、1年間の開発の中で、コーディングを行っていた期間は1ヶ月未満でした。
【開発工程】
01.要件定義
02.外部設計(概要設計)
03.内部設計(詳細設計)
04.単体テスト テストケース作成
05.結合テスト テストケース作成
06.総合テスト テストケース作成
07.コーディング
08.単体テスト
09.結合テスト
10.総合テスト
11.リリース
※私が実際に開発した際の工程であり、同様の手法を使用しても工程は会社やプロジェクトなどで異なります。
っというようにシステム開発≠コードを書くではないよということをわかっていただければ嬉しいです。
現状、上記と同じように開発をしているのかと言われると、答えは「NO」です。
説明が抜けてしまっていましたが、その当時開発していたシステムは、
かなり大規模な組み込み系のシステム開発となっており、開発メンバーも私が知る限りでも100人以上はいるようなものでした。
それをそのまま実行しようとすると、一つのWEBサイトを作成するのに何年もかけることになってしまいます。
もちろん、そんなことはできないため、取捨選択をして工程を簡略化した上で開発を行っています。
では、どの工程をどのようにして簡略すればいいのかっということになるのですが、
どれが正しくてどれが間違いなのか私の中でも整理できていません。
そのため、すこし中途半端になってしまいますが、今回はこのあたりとさせていただきたいと思います。
次回は、ある程度、私の中での考えをまとめて書きたいと思います。
