SOLG System Blog

私がお客様のところでよく尋ねられることの一つに
Webサイトを置くなら、どのサーバーが良いの?というものがあります。

どれが？と言われましても
実はどれでもいいんじゃないかと思う場合も多いのです。

各社サービスにしのぎを削り、細かな部分で違いはあるものの、顧客満足度では大差がないと思うからです。

とはいえ、お客さまのサイトの条件から、選んではいけないサービスというものは確かに存在します。
それは大別して3種類の中からの選択になると思います。

A.資金的に余裕があり、そこそこ安心のサービスを選択する
B.自己責任でお値打ちだけど専門知識が必要なサービスを利用する
C.初心者向けでお値打ちなサービスを利用する

言うまでもなくCを選択してAは期待できません。
Bならば自己責任でがんばれば、Aに近づくことができるかもしれませんが、Cでは無理です。

そして、多くの場合、サイトの作成するお客様はCを選択したがります。
ぶっちゃけて言いますとCに多くを期待をするのは無理というものです。

ですがですね、同時に各社がサービスの充実にしのぎを削っている事実もあるわけです。

そこで、有名ドコロのホスティングサーバの現時点のサービス(2014.11.23)で
私個人の超恣意的な視点かもしれませんが
Cに位置すると思われるサービスについて、調べてみました。

果たして、結構使えるサービスが多くなっているのか?

注目した点はPHPのバージョンです。
PHP5.2、ましてや、5.1.6以下のバージョンしか使用できないサービスだと
現代的なコーディングにはできないので
必然的にアレな、いやいや、誤解なきよう、サービスとして、ちゃんとしているけど、
私がおすすめするとなると・・・んがんぐな、サービスということになります。

結果は以下のとおり。

●さくらのレンタルサーバー
http://www.sakura.ne.jp/plans.html
PHPのバージョンは標準5.2
バージョンは5.2～5.4または4.4を利用できる。
Rubyが使える。

●ロリポップ！レンタルサーバー
http://lolipop.jp/manual/hp/cgi/
PHPのバージョンは5.4.32 ・ 5.3.15 ・ 5.2.17を利用できる。
Ruby1.8.7、1.9.3が使える。

●ヘテムル
http://heteml.jp/service/function/
PHPのバージョンは5.3.28、5.4.27を利用できる。
あとGitが使える。
Ruby1.8.*、1.9.3、2.0.0、2.1が使えるが、Ruby on Rails は非対応。
Ruby on Rails は
http://sqale.jp
をすすめている

●ファーストサーバ
http://www.fsv.jp/spec/
PHPのバージョンは5.3.xを利用できる。

●WebARENA 共用サーバ SuiteX
http://web.arena.ne.jp/suitex/spec/index.html
PHPのバージョンは5.1を利用できる。
Ruby1.8が使える。

●CPIシェアードプラン
http://www.cpi.ad.jp/shared/detail/php.html
PHPのバージョンは5.2.8、5.3.6、5.3.28、5.4.25、5.5.9 、5.5.16を利用できる。
あとGitが使える。

お名前.com 共用サーバー SD
http://お名前.com/server/sd/spec/
PHPのバージョンは5.5.x（初期設定）、5.4.x を利用できる。
Ruby1.8.7が使える。

GMOクラウド iCLUSTA+
http://faq.isle.jp/FaqItem?i_faqId=335&i_categoryId=0
PHPのバージョンは5.3.17を利用できる。
Ruby1.9.3が使える。

●Xserver
http://www.xserver.ne.jp/manual/man_program_soft.php
PHPのバージョンは4.3.9、5.1.6、5.3.3、5.2.x、5.4.x、5.5.xを利用できる。
Ruby1.8.5、1.9.3、2.0.0が使える。

●OCN メール＆ウェブ ビジネス
http://www.ocn.ne.jp/hosting/function/mw2/version.html
PHPのバージョンは5.5.7、5.4.23、5.3.28を利用できる。
Ruby1.8.6が使える。

意外なのですがPHPのバージョンで
結構新し目のものが使えるサービスが多いです。
(5.1.6が多いと思っていました。)
いやー、さすがですね。

反対にRubyについては動くものの
Ruby on Rails が動くサーバとなると
結構、厳しめですね。
というかほとんどは公式では非対応のようです。
情報があったのも、さくらのレンタルサーバーぐらいです。
http://iwatakenichi.blogspot.jp/2007/08/ruby-on-rails-on-sakura.html
(非公式)

共有サーバの世界では
なんだかんだ言ってもPHPが主流のようですね。
(もっといろいろ使えればいいのに)

いろいろと調べた中で
この中で私が良いなぁと思ったのは
・ヘテムル
・CPIシェアードプラン
でしょうか。

何故ならばGitが使用できるので
作成したプログラムをリリースするときにFTPでちまちまアップする必要が無いためです。
GitでPullすれば、それだけで本番に適応できるわけです。

これはすごい便利。

しかし、それはお客さまにとって初心者向けではないし、メリットとはいえないところはあります。
この辺り、結局、選択は難しいですね。

ところで
PHPのバージョンですが
上記のホスティングサービスで、既存ですでに稼働しているプログラムを配置しているサーバも
軒並み、問答無用にバージョンを上げたところが有りました。

案の定、プログラムが動かなくなり
弊社でも困ってしまった事がありました。
制作して年月が経過しているので
当方が勝手にサポートできないのです。(瑕疵担保責任が無いため)

それこそ勝手にやったら、お客さまのデータを勝手に弄ったことになりますから。

冒頭に言ったように
私がお客様のところでよく尋ねられることの一つに
Webサイトを置くなら、どのサーバーが良いの?というものがありますが、
やっぱり、なかなか難しいものがありますね。。

やはり、お客様の条件をご確認させていただきながら
お客様にお伺いした時点の最適なご提案をさせていただく他ないですね。
これからもつど最適解をご提案させていただきます。

というのが今回の結論でした。
  

アプリ開発をしているマツナガです。

弊社では年末から年明けに向けて、新しいiPhoneアプリをいくつか開発しています。iOSのアプリ開発には、Objective-Cという言語を使用します。このObjective-Cという言語、iOSアプリ開発がこんなに盛んになるまでは、Macで動作するアプリケーションを作る言語として存在していましたが（もともとはMac OS XのベースになったNeXTで使われていた言語）、一般的な開発者はふれることのない言語でした。

しかし現在では、iOSの登録開発者数は900万に達しており（WWDC 2014でのTim CookのKeynoteより）、ここに登録されている開発者の大半がObjective-Cを習得して開発を行っています。

そして、WWDC2014では開発者にとって衝撃的な発表がありました。iOS / OS X向けの新しい開発言語「Swift」の発表です。

iOSアプリを開発するために、Objective-Cを学んだ開発者達の悲鳴が聞こえてきそうです。もちろん、Objective-CでのiOSアプリの開発がすぐにできなくなるわけではなく、iOS 8になってもObjective-Cでアプリは開発できます。これまで習得した技術が無駄になるわけではないのですが、ギークな開発者は早々にSwiftに移行していくでしょう(今年WWDCに参加した友人の話では、発表されたばかりのSwiftを使ってプログラムを書き始めた開発者がいっぱいいたとのことです)。

そこで、今後のアプリ開発において、Swiftを採用するかどうかのポイントについて考えてみます。

既存のアプリはどうするか？

すでにObjective-Cで開発されたアプリをSwiftに移行するかどうかという問題です。そもそも、Objective-CのコードをボタンひとつでSwiftに変換する魔法のツールは今現在存在していません。もともと複雑怪奇な文法を持ったObjective-Cのコードをモダンかつシンプルな記述で書けるSwiftに置き換える作業は、結構骨の折れる作業です。一度、数百行程度のコードでトライしてみましたが、とっても辛かったです。すでに公開しているアプリケーションで、大きな改造もなく、保守メンテナンスフェーズにあるアプリに関しては、Swiftに置き換えるメリットはないように思います。また、Swiftで書かれたコードはiOS 7以降しか動作しません。iOS 6での動作保証がマストである場合は、Swiftは選択肢から外れることになります。

新規にアプリを開発する場合どうするか？

まったく新しいアプリを開発する場合、または、すでに公開しているObjective-Cで開発されたアプリを心機一転リニューアルする場合、Swiftを採用するかどうかのチェックポイントです。

1.既存のコードが再利用できるか

まったく新しいアプリを開発する場合でも、これまで開発したObjective-Cのコードを再利用はしたいものです。リニューアルする場合も同様です。これについては、Swiftは、Objective-Cとの互換性を保証していますので、問題ありません。SwiftからObjective-Cのコードを呼ぶこともできますし、Objective-CからSwiftのコードを呼ぶこともできます。
プロジェクト内にSwiftとObjective-Cのコードを共存させる場合には、以下のサイトが参考になります。

F60K - Objective0CとSwiftの組み合わせ方まとめ

また、iOSのライブラリーを管理できるCocoaPodsを使ってインストールできるライブラリーの大半もObctive-Cで書かれていますが、これについても、Swiftのコードから呼び出すことができ、問題なく利用することができました。

Qiita - SwiftでCocoaPodsを使う

2.言語の習得コスト

Swiftは学習しやすい言語かどうかというポイントです。Objective-Cは、C言語をベースにしていると言いながらも、C言語の開発者も戸惑ってしまう括弧[ ]の使い方が独特である点や、そもそも誕生から約30年経過していることもあり、モダンな記法ができるかと言えば、少し無理がある状況ではありました。Swiftはもちろんそういった反省点から生まれた言語ではありますし、今もっとも新しいプログラミング言語であることもあり、他のモダンな言語のいいとこ取りをしているプログラミング言語といっていいでしょう。「Pythonに似てる」、「Rubyに似てる」とか、はたまた「C言語に似ている」とか開発者のつぶやきがTwitterのタイムラインからも見て取れます。そういった意味では、言語としての習得コストは低いと思います。PythonやRubyあたりを使っている開発者であればさほど習得には時間はかからないでしょう。

しかし、言語自体を習得できてもそれだけでは、アプリは開発できません。これはSwiftに限ったことではないですが、アプリを開発するには、そのアプリ専用のフレームワークの使い方を習得することが必要だからです。iOSの場合は、まずは「UIKit」の使い方を覚える必要があります。UIKitは画面を構成するViewやTableViewやボタンなどユーザーインタフェイスに関わる機能を司るフレームワークです。また、画像処理を行うフレームワーク、位置情報を扱うフレームワークなどなど、高機能なアプリを作ろうとすればするほど、覚えなければならないフレームワークは増えていきます。これは、Objective-CでもSwiftであっても覚えなければなりません。ここの習得コストは両者ほぼ同じといえます。逆にいうと、これらフレームワークをObjective-Cを使って覚えた開発者は、この知識をそのままSwiftで使うことができます。これは大きなメリットです。あとは、Swiftの言語を覚えるだけでよいのですから。

では、これからアプリを開発する人は、どちらを選択すればよいでしょうか？ フレームワークについての学習コストは両者同じであるとするならば、学習コストの低いSwiftを選択するのが賢明だと考えます。ただ、現段階では、Objectice-Cに関する参考図書やWebの情報も少ないかもしれません。Swiftをばりばり書いている先輩社員もそう多くはいないと思います。しかしそれは時間の問題です。Objective-Cをバリバリ書いている開発者は、またたく間にSwiftを習得してWebで情報をどんどん発信していくからです。

3.開発効率について

SwiftはObjective-Cよりも、記述を簡略化でき、見通しのよいコードが書ける印象を持ちました。Objective-Cはひとつのクラスを定義するには、ヘッダファイルと実装ファイルの２つのファイル構造になっていましたが、Swiftではひとつのファイルでひとつのクラスを記述することができます。ソースが増えてくると、結構、ヘッダファイルと実装ファイルをいちいち開いて行ったり来たりする時間が無駄だなと思っていたのですが、Swiftではこの作業が軽減できそうです。
言語仕様を習得しさえすれば、記述するコードはかなり減らすことができ、デバッグ工程の作業も減らせそうなので、開発効率は向上すると思います（一方で、iPhone開発は、iPhone 6から画面サイズが増えてしまったのでそのための開発コストといった問題があるのですが、それは別の話）。

いろいろ自問自答した結果、弊社で、年明け頃に公開予定のアプリは、Swiftで書くことに決めました。これまで、いくつもの言語が誕生してきましたが、Swiftは、これまで新たに誕生した言語とは少し違う起源を持ち、違う進化を遂げていく言語なのだと思います。


  

こんにちは。エンジニアの望月です。
みなさんは「IFTTT」というサービスをご存知でしょうか？
わたし自身、気になっていたもののあまり使ったことがなかったので、今回この「IFTTT」の活用法を少し調べてみました。

IFTTTとは？

まずは、「IFTTT」って何？というところから。読み方は「イフト」だそうです。

IFTTT(イフト)は、さまざまなWebサービスを連携させ、タスクを自動化できるサービスです。
「何のサービスをどうするのか」レシピと呼ばれる簡単な設定を作成するだけで連携が可能で、現在は
　・Evernote
　・Twitter
　・Instagram
など、142のサービスを扱うことができます。



例えば、以下はわたしが使用しているレシピです。
■投稿したブログの記事をEvernoteへ保存する

トリガーとしてブログのフィードURLを、アクションとしてEvernoteに新規ノートを作成するよう登録しました。
ノートのタイトル、内容、タグなど細かく設定することもできます。

使って便利・楽しい！おすすめレシピ

レシピは、自分で作成するだけでなく、誰かが作成したものを使用することもできます。
その中から、気になるレシピをご紹介します。

■Facebookでタグ付けされた写真をDropboxに保存する

　ーDownload Facebook Photos you're tagged in to Dropbox
FacebookとDropboxをIFTTTと連携するだけで、自分がタグ付けされた写真をDropboxにフォルダを作成し自動保存してくれます。
もちろん、ファイル名や保存するフォルダーの指定をすることもできます。

■退社したことをSMSで誰かに知らせる

　ーLetting the spouse know you've left work
位置情報を利用して、職場を離れた時に自動でSMSを送ることができます。
家族や恋人に、「今から帰るよー！」とお知らせをするのにいかがでしょうか？

SMSの登録をする際に注意することは、IFTTTが海外サービスだということ。
日本の携帯番号を登録する場合は、日本の国番号をつけなければいけないので
「00 + 81 + 頭の”0″を抜かした携帯番号」となります。
※残念ながら、まだ日本語のメールには対応していないようです。

SMSではなく、メールアプリを使ったりツイートしたりという使い方もできますね！
メールを使用した例が↓こちら。

■エリア51で画像が投稿されたら、メールで通知する

　ーThe truth is out there... Email me Instagram photos taken at Area 51
このレシピには、UFO多発地帯と言われているエリア51の位置がすでに登録してあり、instagramで画像が投稿されたらメールで通知してくれます。
怪奇現象好きのわたしにはもってこいのレシピです・・・早速追加しました。

■Foursquareでチェックインしたら、Googleカレンダーに登録する

　ーAdd your Foursquare checkin history to your Google Calendar
いつ、どこにいっていたのか、カレンダーに登録してあとから見返すのに便利ですね！

■明日雨が降るときにだけお知らせする

　ーRain tomorrow? Get an iOS Notification
天気予報をチェックするときに、一番気にするのは「雨」ではないでしょうか？
登録した地点の明日の天気が雨のときだけ通知してくれるため、傘を忘れずにすみそうです。
Android版もあります。　Rain tomorrow? Get an Android Notification


その他、人気のレシピをこちらから探すことができます。
テーマに沿って特集もされていて、見ていると使ってみたくてワクワクしてきますよ！

まとめ

・自分でレシピを作成する
・他人が作成したレシピを使う
・他人の真似をして自分好みに作成し直す
と、さまざまなサービスを組み合わせ自由に設定することできます。
IFTTTを使って便利に暮らしたり、新しいサービスを生み出したり、、、
無限の可能性を体験して楽しみましょうー！