開催日:2015年7月22日主催：株式会社システムキューブ後援：和歌山県経営者協会会場：和歌山ビッグ愛505会議室 弊社WEB制作営業を務める大鋸を講師に、SEOでホームページをアクセスアップする方法について講演、和歌山市内での第二回目になります。今回も定員いっぱいのご参加をいただきました WEBでアクセスを上げ、集客につなげるための技法SEOを具体例で説明させていただきました。 また競合よりも強いサイト作りや、アクセス解析にも触れ、より確実にWEBを活用していくためのノウハウをお伝えし、WEBサイト運営で行うべきことをお持ち帰りいただける内容となりました。
ニューカマー KTです。 さて、今回第１弾としての「システムおじさんのひとり言」は 私が初めてプログラムを組んだCOBOLについてです。 ここ最近はいろいろな言語がありますが、 私の世代ではCOBOLやアセンブラなど今ではメジャーでない言語が活躍しておりました。 今のような簡単に作成でき、デバッグもしやすい言語ではないので 作成するためにいろいろ工夫をしてましたし、 少しでも見やすくなるようなコーディングを心掛けていたように思います。 今でもたまにCOBOLをみますが、作った人の魂を感じることがあり 命令は少なかったです（あまり知らなかっただけです）が その分作り甲斐があったように思います。 そんな私も今ではVB.NETやその他諸々の言語を見ることになり時代も変わったと思う 今日このごろです。 次回は「思い出のWindows３．０」でお会いしましょう。
スマートフォンは、中高生から高齢者まで、かなりの普及がみられます。 インターネットは、Webサイト、Webニュース、SNS、ソーシャルゲームまで、すべてのインフラになっています。 パソコンを自宅に持たない、スマートフォンのみの利用者は、光回線などの設備を持たず、携帯電話の通信ですべて賄う人が多くなってきました。 このような利用法の方が、今後自宅にパソコンを持って、光回線などを新たに契約するのかというと、そこまでする割合は小さくなっていくと筆者は考えます。 携帯のデータ通信で¥5000/月ほどする上に、あらたに光回線を契約するのは、あまりにも月額の利用料が高くなってしまいます。 現在スマートフォンで間に合っている多くの方は、わざわざパソコンを持たなくても、と考えているのではないでしょうか。 もちろん持ち帰りの仕事など、自宅でパソコンを使わなければならない人は、今後も一定の割合でいて、減ることはないと思います。 スマートフォンが置き換えるのは、あくまで個人向けのコンピュータです。 仕事にコンピュータを利用する、という考えは1950年代から延々と続く歴史を持っていて、個人向けのコンピュータより歴史は深いです。 汎用機と呼ばれる大型のコンピュータは、公共や企業の基幹業務用として変わりなく使われ続けるでしょうし、そこまでの設備を必要としない企業にとって、IAサーバー、ワークステーション、パソコン、そしてこれからクラウドは大きな役割を持ち続けるでしょう。 パソコン単体でも十分な能力を持つようになって、自宅のパソコンで仕事の続きができるようなワークスタイルは、成立してまだ20年も経っていません。 ただスマートフォンはインターネット、デジカメ、音楽、ゲームなどを主にする層をパソコンから引き離すだろうと考えます。 スマートフォン利用者でパソコンを持てば便利になるだろうけど、そこまでの投資に効果が見いだせない場合、スマートフォンに留まることを選ぶはずです。 おそらくこの流れは、変わることはないと筆者は考えています。 そういったユーザーをどう取り込んでいくのかが、今後のBtoCのビジネスにとって大きな課題でもありますし、大きな市場として見込まれるでしょう。 Flashを利用していたり、InternetExplorerで閲覧することを前提にしたWebサイトなど、まずパソコンありきでスマートフォンユーザーを置き去りにしたサービスなどは、前提からの見直しをしなければならなさそうです。
こんにちは。たはらです。 弊社ではWebデザイン等でAdobe製品を使う為、Creative Cloud(CC)を契約しています。 先日、Photoshop CC 2014をDELLのPC(Optiplex 7010)にインストールしたのですが、起動してから10秒程度経過すると、「Adobe Photoshop CC 2014 は動作を停止しました」と表示され、強制終了されてしまう現象が発生しました。 インターネットで調べてみると、VGAのドライバの更新で改善したという報告があがっていたので試してみたが改善せず。。。 さらにWindowsUpdateやBIOSのアップデートも片っ端から適用したがそれでも改善せず。。。 Photoshopを再インストールし直しても改善せず。。。 何か方法がないかと考えていたところ、起動してから10秒は操作できる時間があるので、その間に設定画面でVGA関係の設定を変えれば！と思い付きました。 起動してすぐさまメニューバーの[編集]をクリック。すぐさま[環境設定]⇒[一般]と進んでいく。 ここまでは順調。 そこからVGA関係の設定がどこにあるかを探す。 [インターフェース]は違う、[設定を同期]も違う、そうこうしているうちに10秒経過して強制終了。 再度同じ手順で関係しそうな設定がないかを探す。 すると[環境設定]の[パフォーマンス]にグラフィックプロセッサーの設定というものが！ とりあえず[グラフィックプロセッサーを使用]のチェックをオフにし、[OK]としようとしたところ、またまた強制終了。。。 挫けずに、今まで磨きあげた素早いマウスさばきで設定変更し、Photoshopを通常終了させる。 そして起動してみる。 10秒…20秒…30秒…1分経過してもエラーメッセージは出ません！ 無事、Photoshopを使えるようになりました。 [グラフィックプロセッサーを使用]が何に影響するかは分かりませんが、とりあえず解決しました。 めでたしめでたし。
まいどどうも(ｏ´・∀・)o 久々に連載再開します。 前回までで、 ・ウィンドウを作ることと、 ・ウィンドウに絵を表示すること ができました。 ちなみに、この連載での最終的な成果物は↓これです。 （紫色のチビ忍者が、パソコンの画面の中でｼｭﾀﾀﾀﾀ…と、勝手に動くのを想像してください。） （１）デスクトップマスコットの仕組み さて、この連載でのデスクトップマスコットは、 いったいどういうからくりで動くものなのかというと… ・透明なウィンドウ（目に見えないウィンドウ）に、 ・マスコットキャラの絵を表示して、 ・その絵を動かす これだけです。シンプルですね。 順に説明しますよ。 まず、透明なウィンドウ。 これは、ＤＸライブラリにその機能があります。便利ですなぁ。 （具体的なやり方は、この回のおしまいにお見せしますよ。） 次に、マスコットキャラの絵を表示する。 これはもうできますね。 DxLib::LoadGraph()して、DxLib::DrawGraph()するのでしたね。 最後、絵を動かす。 さあ、これです。絵を動かすことがこの連載の本質であり、その第一歩が、この第４回なのです。 （２）絵を動かす仕組み まずは、以下をご覧あれ（GIFアニメです）。 さて、この絵はどうやって動いている（ように見える）のでしょうか。 もちろんパラパラ漫画と同じ原理です。 高速に絵を切り替えてるだけです。 （ここでは３枚のパターンの絵をいい感じにパラパラさせてます） デスクトップマスコットも同じです。 つまり、高速に絵を切り替えるということを、プログラムでやればいいのです。 （３）メインループという考え方 パラパラ漫画は、たくさんの紙に、それぞれの瞬間の絵を描きますね。 ところが、デスクトップマスコットは、ウィンドウというひとつの紙しかありません。 ではどうするかというと、 ひとつの紙に、絵を出したら、すぐにその絵を消して、次の絵をだす…といったことをすればよいのです。 描画 ⇒ クリア ⇒ 描画 ⇒ クリア…。 というイメージですね。 実際には、どのタイミングでどの絵を、どの位置に出すべきなのかといった、 演算（計算）をする必要もあるので、 演算 ⇒ 描画 ⇒ クリア ⇒ 演算 ⇒ 描画 ⇒ クリア…。 があるべき姿となります。 疑似コードで表すと、こうなります。 [cpp] int WINAPI WinMain( /*省略*/ ) { // 無限ループ処理 while( /*省略*/ ) { // 演算 Update() ; // 描画 Draw() ; // ウィンドウの中を全部クリア Clear() ; } // プログラム終了 return 0 ; } [/cpp] Clear()は、ウィンドウの中を全て空っぽにします。 一部分だけを消す、といったことはしません。 つまり、毎回、ウィンドウの中を全部描きなおすのです。 こういう無限ループのことを、メインループとかゲームループとか言いますが、 デスクトップマスコットのプログラムというのは、 このメインループの中のUpdate()とDraw()の中身を作ることに他なりません。 自分だけのロジックを、メインループの中にひたすらプログラミングしてゆく…。 この感覚は、イベントドリヴンなWindowフォームアプリや、 Post/Getがトリガーとなるブラウザアプリの開発しかやったことが無い人には、 なかなか刺激的な体験になると思います。 （４）ついでにダブルバッファリング さて、メインループの中で描いたり消したりを繰り返すことで、ある問題が起こります。 メインループというのは、１秒間に何十回という超高速なペースで繰り返されるものですが、 実際にやると、チカチカと点滅して見えてしまうのです。人間の眼は優秀です。 ではどうするかというと、 見えない紙に先に下書きして、見せたいタイミングになったら、見える紙に複写する。 こういう手法を取ります。 これをダブルバッファリングと呼びます。 この連載の中では、 見えない紙のことをウラ画面と呼びます。 見える紙のことをオモテ画面と呼びます。 描画とクリアを繰り返すのはウラ画面で行い、描画後の瞬間だけ、オモテ画面に反映するのです。 疑似コードで表すと、↓こうなります。 [cpp] int WINAPI WinMain( /*省略*/ ) { // 無限ループ処理 while( /*省略*/ ) { // 演算 Update() ; // ウラ画面に描画 DrawUra() ; // オモテ画面に複写 CopyOmote() ; // ウラ画面の中を全部クリア ClearUra() ; } // プログラム終了 return 0 ; } [/cpp] こうすることで、オモテ画面には常に絵が見えている状態になり、チカチカしなくなるのです。 （５）今回の成果コード 色んなパターンの絵を切り替える、ということはさておきで、 先ほどまでの疑似コードをちゃんとコーディングするとこうなります。 ウィンドウの透明化の方法も書いておきますよ。 [cpp] #include <DxLib.h> // ＤＸライブラリを使います //************************************************************** // 定数宣言 //************************************************************** // 描画スクリーン（ウラ・オモテ画面）のサイズ static const int SCREEN_SIZE_W = 200 ; // 幅px static const int SCREEN_SIZE_H = 200 ; // 高px //************************************************************** // WinMain関数(プログラムはここから実行されます) //************************************************************** int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) { //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // １．ＤＸライブラリの使用前の準備 //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ウィンドウを透明に設定します DxLib::ChangeWindowMode( TRUE ) ; // ウィンドウモードにします DxLib::SetGraphMode( SCREEN_SIZE_W, SCREEN_SIZE_H, 32 ) ; // 描画スクリーンのサイズを指定します DxLib::SetWindowStyleMode( 2 ) ; // ウィンドウのスタイルを枠無しにします DxLib::SetUseBackBufferTransColorFlag( TRUE ) ; // ウィンドウを透明にします //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ２．ＤＸライブラリの初期処理(ウィンドウを生成します) //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ //------------------------------------ // ２－１．ウィンドウの生成 //------------------------------------ if( DxLib::DxLib_Init() != 0 ) { // 失敗したら直ちに終了します return -1 ; } //------------------------------------ // ２－２．画像を描画する画面の設定 //------------------------------------ // オモテ画面を作ってハンドルを得ます ※ウラ画面はＤＸライブラリが最初から用意しています const int omoteHandle = DxLib::MakeRGB8ColorSoftImage( SCREEN_SIZE_W, SCREEN_SIZE_H ) ; // ウラ画面(みえない画面)に描画するように設定しておきます DxLib::SetDrawScreen( DX_SCREEN_BACK ) ; //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ３．デスクトップマスコットの初期処理 //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // マスコットの画像をメモリにロードしてハンドルを得ます const int graphHandle = DxLib::LoadGraph( "GRAPH/TEST_GRAPH.png", TRUE ) ; //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ４．メインループ //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // Windowsからのメッセージ処理を行いながら永遠にループします while( DxLib::ProcessMessage() == 0 ) { // 演算 // まだやることないでゴザル(ｏ´・∀・) // ウラ画面(見えない画面)に描画 DxLib::DrawGraph( 0, 0, graphHandle, TRUE ) ; // ウラ画面(見えない画面)の内容をオモテ画面(見える画面)に複写します DxLib::GetDrawScreenSoftImage( 0, 0, SCREEN_SIZE_W, SCREEN_SIZE_H, omoteHandle ) ; // オモテ画面(見える画面)の内容をウインドウに反映します DxLib::UpdateLayerdWindowForSoftImage( omoteHandle ) ; // ウラ画面(見えない画面)の中を全部クリアします DxLib::ClearDrawScreen() ; } //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ５．デスクトップマスコットの終了処理 //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // マスコットの画像データをメモリから解放します DxLib::DeleteGraph( graphHandle ) ; // オモテ画面の領域をメモリから解放します ※ウラ画面はＤＸライブラリが勝手に破棄してくれます DxLib::DeleteGraph( omoteHandle ) ; //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ６．ＤＸライブラリの終了処理 //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // ウィンドウを破棄してＤＸライブラリが確保したメモリ領域などをすべて解放します DxLib::DxLib_End() ; // プログラム終了します return 0 ; } [/cpp] 知らない関数ばっかり出てると思いますが、関数を覚える必要はないです。 大事なのは何をやってるのかわかる、ということです。 全部日本語でコメント書いてるからわかるでしょう。 ちょっとだけ解説すると、ウラ画面とオモテ画面をどちらも200*200というサイズで作っています。 そして、ループで、ウラ⇒オモテに転写してウィンドウ内の表示を更新しています。 転写するためにはウラとオモテがぴったり同じサイズでなければなりません。 実行すると↓こうなります。 前回の絵を流用してるので（一枚しかないので）、パラパラしているようには見えませんが、 実際には目にもとまらぬ速度でパラパラしているのです。 次回へ続くドンヾ(´･∀･｀)
Windows10から標準のWebブラウザがInternetExplorerからEdge(エッジ)に変更されます。 Internet Explorerは互換性のために従来通り利用できますが、Edgeがインストール時の標準となるようです。 Internet ExplorerはActiveXなどを利用した業務用のシステムなどのための互換性を保持するため、他のブラウザとはちがい、かなりの独自性があります。 その分Web制作の現場ではInternet Explorerのための動作検証や、対応を必要とされることも多いです。 Internet Explorerだけを使っている方には、あまり関係のないお話かもしれません。 WebシステムでInternet Explorerでは十分に動作しないものがある場面も出てきており、FirefoxやChromeなどのブラウザにシェアを奪われないために、Edgeが標準ブラウザになっているのかと思います。 EdgeはWebkitというオープンソースのブラウザとの互換性を持つとマイクロソフト社が宣言しているようです。 Webkitを搭載したブラウザはiOSなどのSafari、ChromeもWebkitから派生したものを利用しています。 今後独自Webサービスをスタートする時も、Internet Explorer限定であればスマートフォンをはじめとしたユーザーに届かなくなります。 ブラウザは今後、さらにアプリケーションのプラットフォームとして重要視されるはずです。 パソコンのInternet Explorerで動作する、という強みから一度距離を置き、様々なデバイスで利用できるWebサービスのプラットフォームとしてEdgeを押し出していくのではないでしょうか。
Mozilla、Google、Microsoft、AppleがWebアプリケーションの高速化のための規格、WebAssemblyを共同で開発していくことを明らかにしました。 各ブラウザにはWebアプリケーションをJavascriptで実行させる機能を持っています。 JavascriptはHTMLで記述できない細かな動作からスタートし、現在Javascriptエンジンの高速化によってブラウザ上といえどアプリケーションをかなり高速に動作する環境が整ってきました。 JavascriptはソースコードをHTMLファイルとともにブラウザに読み込ませますが、このソースコードはテキストで書かれており、これをブラウザが解釈し、コンパイルして実行可能にします。 WindowsでいうEXEファイルのような実行可能なバイナリフォーマットであれば、機種依存性、あるいはブラウザ依存性が出てきます。 Javascript実行の仕組みはおおよそどのブラウザでも備えていますが、それ以上の独自規格でない、共通な仕組みを新たに加えるのはWebAssemblyが最初です。 WebAssemblyはJavascriptを解釈した状態のバイナリフォーマットで配布されますので、読み込みが早く、またすぐに実行できる仕組みです。 このWebAssemblyで利用されるバイナリフォーマットは、JavascriptだけでなくC言語や、その他言語でも作成できるようになります。 あくまで現状のブラウザにWebAssemblyの読み込みと実行の仕組みを追加する仕組みで、別途プラグインなどをインストールするJAVAなどとは方式が違います。 ブラウザ上でかなりのことができるようになり、またスマホでもWebアプリを高速化し、より使いやすい物になります。 現在主流のWebブラウザ開発元が共同して開発するWebAssemblyで、パソコンやスマートフォンの使い方にも変化が訪れるかもしれません
WindowsのタスクトレイにWindows10へのアップデートを予約するアイコンが常駐するようになりました。 業務でWindowsを利用されている場合、大方の人は性急なアップデートは行いたくはないはずです。できなくなること、動かなくなるアプリを事前に全て検証するのは大変時間のかかることです。 インストールするパソコンの最低限の性能はWindows8とほぼ変わりありません。 Windows7が動作していたパソコンで製造時期が古いものは、一部対応していないものもあります。 Windows10へのアップデートアイコンから互換性についてはチェックできます。 .NETフレームワークは3.5の機能を追加すると従来までの.NET製のアプリケーションは動作するようです。そのあたりはOSにほとんど依存しない.NETの利便性です。 .NETフレームワークのおかげでWindowsのバージョン間の互換性については随分と問題が減りました。 プリンタなどのデバイスドライバは大手については対応を始めているのではないかと思われます。 アップデートするかどうかの大きな判断として、利用している周辺機器のドライバが対応するかどうか、もあります。 現在Windows8以降を使われている方でも、当面は様子を見るという方も多いのではないでしょうか。 Windows7,8からの無料アップデートの期間は一年間設けられています。 かつてはサービスパックがリリースされるまで様子を見るという方も多かったようですが、Windows8ではサービスパックそのものがなかったこともあり、評判を聞くなど、様子を見ながら、ということになりそうです。
クラウドサービスの大きなメリットは最低限の機能からスタートできるところです。 パッケージソフトでは、ほぼ全ての機能を設計までの段階から用意し、すべて実装、テストをしてリリースに至ります。 パッケージソフトでは設計やプログラミングなどの実作業に入れば、その段階での機能追加は難しいので、仕様の決定は厳密に行われます。 クラウドサービスのパッケージソフトと違うところは、まず最低限の利用者数と機能でスタートしていくことができることです。 利用者が増えるうちに、ニーズも増えていきます。そのニーズの中でも声の大きいものを採用し、さらなる利用者獲得のためにバージョンアップを短いサイクルで繰り返していくことができます。 安全性や、様々な場所で同じサービスを使えるなど、クラウドの強みはいろいろとありますが、このバージョンアップのサイクルの短さや、スピード感もその利点の一つです。 クラウドは、最初はあまり様々な機能がなく、コアとなる部分からサービス開始することが多いです。 その際に機能の優劣で他のパッケージソフトと比べると見劣りして、また未完成品の様に感じてしまうことは否めません。 ただ機能や使い勝手についてはほぼ確実に良くなっていくことを見越し、少しずつ小さい部分から導入していくことなどで評価し、また要望を寄せることができます。 クラウドは買いきりではなく月額や年額での利用料の形が多く、このような製品の特性に沿ったものです。 またどれだけ機能拡張されても、利用料が上がることは稀で徐々にコストパフォーマンスが増していくものという見方もできます。
クラウドストレージのDropboxにファイルリクエスト機能が追加されました。 従来Dropboxユーザー間でのファイルの受け渡しは共有されていれば、自分のDropbox領域へのコピーは簡単に行うことができました。 今回のファイルリクエスト機能はファイルリクエスト用のフォルダを作り、そのリンクを作成しアップロードを依頼する人にURLを送ります。 URLを受け取ると、以下のようなページが表示されます。 この画面から複数のファイルをアップロードできます。 アップロードしたファイルはアップロードした本人にも見ることができません。 アップロードをリクエストしたDropboxのユーザーが共有設定をしない限り外部から見ることはできません。 URLを他の人と共有せず、アップロードが終わればすぐにファイルリクエストフォルダを削除することで不要なアップロードを防ぐことができます。 メールへのファイル添付などでは難しいファイルの共有を行うためには手軽で使いやすい方法だと思います。