お知らせ

  • パソコン関連

Windows7のサポート期間終了まであと2年

noimage

Windows7のサポート期間終了まであと2年

Windows7の延長サポート期限は2020年1月。それ以降はセキュリティを含めたアップデートは行われません。 現在2018年から残すところあと2年を切りました。 Windows XPサポート終了が2014年でその際に駆け込みのアップデートや機材調達で納期の遅れなどが頻繁にありました。 今年2018年中のWindows7からWindows10へのアップデートのプランづくりをおすすめいたします。 Windows10は2015年にリリースされて3年、成熟したOSとなってきています。 その前バージョンWindows8.1も今年に正規サポートが終了され、延長サポート期間に入ります。いまWindows8.1に移行するよりはWindows10への移行をおすすめします。 今までもこれからもOSのセキュリティアップデートはパソコンを業務で使う上で最も大切なことです。 幸いWindows7とWindows10はユーザーインターフェースも違和感が少なく、また周辺機器のデバイスドライバなどもOSアップデートに追従しているものが多くなっています。 Windows XPからWindows7へのアップデートは周辺機器の対応状況などもかなりの変化があり、急な移行によって周辺機器も新たに調達する必要があったという背景もあります。 早めのOSアップデートプランを立て、Windows7のサポート終了に備えることで直前で移行プランがうまくいかないなどの混乱をうまく避けていきましょう。

  • パソコン関連

プロセッサ起因の脆弱性MeltdownとSpectre

noimage

プロセッサ起因の脆弱性MeltdownとSpectre

2017年末にパソコン、スマホ、IoT機器などのプロセッサ起因の脆弱性MeltdownとSprctreが公表されました。 これについてOS各社などが対策用のアップデートを行なっています。 先月から現在にかけての最新版アップデートを行なっていない人はすぐに適用するようにしてください。 これはOSやアプリケーションなどのソフトウェアが原因の脆弱性ではなく、コンピュータの計算機能を集約するプロセッサの脆弱性となり、影響範囲はかなりの大きさとなります。 個人用のパソコン、スマホなどにとどまらず、Webサーバーやその他組み込み型のものなどでも同じリスクを追うことになります。 ひとまず目の前のもののアップデートを先んじて行えば、個人としての対応は終わりです。 近年のプロセッサは予測実行や投機的実行という機能を備えており、これはプログラムの命令群を順番どおりでなく後の命令でも早く実行できるものから実行していくことにより処理速度の向上を図る設計になっています。 この機能の欠陥により、一つのプログラムが他のプログラムのデータを任意に取得することができるようになるというもので、例を挙げるとブラウザで動作するJavascriptが他のアプリやOSのパスワードを読み出すことができるようになるということがこの脆弱性の概略です。 これはIntelの代表的なプロセッサCoreシリーズやスマートフォンタブレットのARM系のプロセッサも同じ設計になっているため、今回発見された脆弱性は広範囲に及びます。 この問題を解決するためにはソフトウェア側で投機実行や予測実行の機能を部分的にオミットしていく必要があります。 そのため脆弱性修正後にパフォーマンスに大小の影響がでるということになります。 個人向けのパソコンよりも大規模なWEBサーバーなどでのパフォーマンス低下がかなり大きな影響を及ぼすことになりそうです。 根本的な修正のためにはプロセッサの入れ替えが必要になり、それをパフォーマンスを低く抑えながらソフト側で対応する状況となっています。

  • ブログ

スマートディスプレイ

noimage

スマートディスプレイ

おはこんばんちは。大阪のたはらです。 先日堀川戎神社へお参りしたのですが、帰る直前にすごいあられが降ってきました。 年始早々波乱の予感です。 去年はAmazon、Google、LINEなどがスマートスピーカーを発売して話題になりました。 AIを使った音声アシスタントで、音楽鑑賞や買い物、家電を操作したりできます。 ネットニュースや雑誌などでも多く取り上げられていたので、ご存じの方も多いと思います。 で、つい先日、「CES2018」でGoogleアシスタントに対応した「スマートディスプレイ」が各社から発表されました。 タッチディスプレイ付きのスピーカーのようなもので、スマートスピーカーの機能プラス、テレビ電話、動画や写真の閲覧などができます。 個人的にはスマートスピーカーは音声での操作となり少々使いづらい印象がありましたが、「スマートディスプレイ」は画面表示やタッチパネルによって、より直感的に使えるようになったのではと思います。 Amazonは先行して「Echo Show」という製品も販売しています。 2018年も音声アシスタント市場に目が離せません。 それではまた。 #GoogleとAmazonはもう少し仲良くして。

  • パソコン関連

ノンプログラミング業務アプリ開発

noimage

ノンプログラミング業務アプリ開発

業務用のアプリケーション開発には開発ツールを利用してプログラムを作成する必要がありましたが、最近は簡単な業務に使うアプリはプログラミングなしで開発できる環境が増えてきています。 国産ではKintoneのように、現在Excelで運用しているような社内データをアプリ化することができ、またその他社内での書類申請ワークフローなどもどんどんプログラミング不要で開発してくことができます。 このようなプラットフォームはこれからどんどん増えていくようです。一つはWEBアプリ化が簡単にできれば、スマートフォン対応なども特別な開発なしで作成できることも大きいでしょう。 PC、スマートフォン、タブレットでそれぞれ別の画面サイズに合わせて、別の開発ツールが必要になるとアプリケーション作成は難しく、またコストも大きくかかります。 これらをWEBアプリ化することは、プラットフォームの垣根をなくすものです。 海外ではSalesForce社のForce.comが大手で、データベースを利用したWEBアプリがノンプログラミングで開発可能です。 ここに大手であるMicrosoftがPowerApps、GoogleがAppMakerでそれぞれ参入してきています。競争が激しくなることでより一層に洗練されたものになりそうです。 複雑なビジネスロジックを持ったアプリケーションは今後もプログラム製作のコストを必要とするでしょう。より簡単なものはノンプラミングアプリであればプログラミング技術を問わずに作成することができるようになり、IT化クラウド化が一層強化されていくと思われます。

  • パソコン関連

2017年を振り返って

noimage

2017年を振り返って

2017年も終わろうとしています。今年のIT業界などの出来事を振り返ってみたいと思います。 この一年、ブロックチェーンやビットコインなどが大きく取り上げられたように感じます。 ブロックチェーンやビットコインは2000年代後半ぐらいからの歴史がありますが、大きく国内メディアで取り上げられることが増えました。 ブロックチェーンは信頼性の高いデータのやり取りが一極集中ではなく分散型でできることで、仮想通貨以外にも様々な分野で利用されます。これが国内でも浸透していきそうです。 その他にはAIや深層学習についての話題も多かったように感じます。 AIやブロックチェーンのためにはGPGPUを利用した膨大な計算が必要なこともあり、普及とともにGPUメーカーが大きく伸びていくことになりそうです。 Google HomeやAmazon Echoなど家庭用音声アシスタントが国内でもサービスが始まり、これらも2018年以降に普及していくでしょう。これらの音声アシスタントは音声データをたくさん取得すればするほど賢く、聞き取りも上手になっていきます。 2017年は浸透の一年であったように感じます。これら技術の普及と浸透が、2018年以降により新しいサービスに実を結ぶことになりそうです。

  • ブログ

IchigoJam

noimage

IchigoJam

こんにちは!、かわせです。 今日本社で日経パソコンを読んているとIchigoJamの記事を見かけました。 ネットで調べてみるとプログラミング学習用の子供パソコンだそうです。 https://ichigojam.net/ なんと構成はCPUとUSBポート、モニタようにビデオ端子、電源供給用のマイクロUSB端子のみで OSの代わりにBASICがのっかっておりプログラミングがすぐにできるといった代物。 そういや昔々の大昔に、COMPO BS/80 というNECのTK80ワンボードマイコンにBASICをのっけた機械とほぼ同じような感じです。 COMPO BS/80は一式そろえると何十万円もしましたがIchgoJamは5千円オバーで手に入るようです。 面白そうなので買おうかと思ったら品切れでした。 残念!  

  • ブログ

JBossでRESTful APIを作ってみる

noimage

JBossでRESTful APIを作ってみる

はじめに JBossつったら、SOAPだろ。と思っておりました。 とある事情でRESTful APIを作らねばならなくなりました… RESTful対応するには javax.ws.rs.core.Applicationを継承したクラスを作る。 @ApplicationPath("/api") public class RestApplication extends javax.ws.rs.core.Application {} ApplicationPathのアノテーションを付けたパス以下がRESTfulになります。 web.xmlにjavax.ws.rs.core.Applicationのservlet-mappingを追加する。 <servlet-mapping> <servlet-name>javax.ws.rs.core.Application</servlet-name> <url-pattern>/api/*</url-pattern> </servlet-mapping> url-patternのパスがRESTfulになります。 どちらか対応すればよいです。 APIクラス HTTPメソッドのアノテーションをつければAPIになります。 @Path("/") public class Api { @GET @Path("/hoge") public String Hoge(@QueryParam("key") String key) { return "input key=" + key; } } @Pathや@QueryParamアノテーションを付けると、メソッド名や変数名に関係なくパスやパラメーターが設定できます。 APIパラメーター @QueryParam URLのクエリーパラメーターから設定されます。 /api/hoge?key=value @FormParam HTMLのformの値から設定されます。(POSTのみ。) <form><input type="text" name="key"></form> その他 @PathParamや@HeaderParamなんかもあるそうです。 HTTPステータスコードを設定 メソッドの戻り値をjavax.ws.rs.core.Responseに変更し、statusメソッドで設定する。 public Response Hoge(@QueryParam("key") String key) { return Response.status(Status.INTERNAL_SERVER_ERROR).build(); } ステータスコードと共にテキストを設定したい場合は、entityメソッドで設定すればよい。 public Response Hoge(@QueryParam("key") String key) { return Response.status(Status.INTERNAL_SERVER_ERROR).entity("内部エラー").type(MediaType.TEXT_PLAIN).build(); } まとめ 案外難しくないなーと思いました。 このままだと、パラメーターがUTF-8になってなかったりしますが… RESTful APIだとHTTPステータスコードも重要なので、Response返すようにした方が良さそうかなと感じました。

  • パソコン関連

メールで実行形式のファイルを添付する危険性

noimage

メールで実行形式のファイルを添付する危険性

電子メールには様々なファイルが添付できますが、ここに実行型のファイルを添付することはリスクが高い行為です。 Gmailを始めオンラインメーラーでは実行型のファイルを添付できない、またzipファイルを転送する際にもexeなどの実行型ファイルを添付不可能になっているものがほとんどのはずです。 exeという拡張子だと添付できないのでex_のようにして送付することなどもこれに当たります。 自動展開型の圧縮ファイルのようなものも実行型ファイルになり、これらの送付は常にリスクを伴うものです。 実行型ファイルのメールでのやりとりが常態化していると、送信先の不明あるいは偽装されたメールに添付された実行型ファイルを実行してしまうリスクが付きまといます。 電子メールは送信経路での暗号化がないことや、送付元の変更などは自由にできることは前提として考えなければいけない通信手段です。 これらのファイルを送信受信するときには、オンラインストレージを利用するのがもっとも安全です。 送信受信ともに期限付きリンクを利用して相互に送り合うことができれば、ファイルの漏えいや誤った送り先を選択してしまうなどのリスクは無くなります。 ファイルの転送については企業向けDropboxのようなオンラインストレージを使うことがもっとも安全性の高い手段と考えます。 通信経路にはSSLによる暗号化が施されており、偽装された転送先に誘導されてしまうということも起こりえません。 メールによるフィッシングがいつどこにでもありうる状態になった今、特に実行型のファイルのやりとりをメールで常態化させることは危険といえるでしょう。

  • ブログ

システム今昔物語(その2)

noimage

システム今昔物語(その2)

大台を超えたTKです。 今回は私が経験した昔のシステムと 今まさに経験しているシステムで感じていることを 書いていきたいと思います。 昔の開発言語もいろいろありましたが 汎用機をサポートしていた私は COBOL一辺倒でした。 COBOLは命令が簡単だったのですが いろいろ工夫する場合には、 なかなかおもしろかったです。 今の言語は命令がありすぎて使いこなせません。 そんな私がVB.NETと出会ったのが10年前ぐらいでした。 誰も修正する人がいないので 一度やってみようと思い始めました。 COBOLオンリーの私には衝撃的でした。 VISUALSTUDIOを使う、命令はどんどん出てくる プログラクがファンクション化されている 正直覚えられないとは思ってました。 ただ、COBOLで培ったプログラム力は なかなかなもので、VB.NETでCOBOLを 作る感覚が芽生えました。 我流ですが、何とか覚えることができ ちょっとした内容なら使えるレベルになりました。 今は言語が多種多様で覚えるのが大変だと思いますが 1つプログラムを覚えていると、 何とかなるかも知れないとは思っています。 ちなみにACCESSもおぼえやすいと思います。 次回は「VSAMとORACLE」でお会いしましょう。

1 18 19 20 21 22 71