お知らせ

  • パソコン関連

GitHubが無償ユーザーにプライベートリポジトリ提供

noimage

GitHubが無償ユーザーにプライベートリポジトリ提供

オンライン型のバージョン管理システム最大手のGitHubは、小規模・個人向けの無償サービスでもプライベートリポジトリを利用が可能となりました。 小規模・個人のユーザーもリポジトリを公開せずにGitHubを利用することが可能となります。 GitHubはそれまで無償ユーザーにはパブリックリポジトリの作成のみを認めており、無償でGitHubを利用する場合全てのコードやプロジェクトを公開した状態でのみ利用できました。 これはオープンソースプロジェクトや個人の作業用などには無償で使えるサービスでありましたが、商用でコードを公開したくないものなどでは無償では利用できない形となっておりました。 プライベートリポジトリは有償ユーザーに提供されているのみでしたが、今回のサービス内容変更で共同作業者が三人までの小規模なプライベートリポジトリを無償ユーザーでも無制限に作成可能となりました。 プライベートリポジトリで多数人での参加が必要となる場合は、月額7$の有償プランが今後も必要となります。 GitHubがマイクロソフト社によって2018年に買収されて以降で最初の大きなサービス変更で、個人利用者にとってもよりGitHubが使いやすくなる変更でしょう。

  • ブログ

Resharper試用開始

noimage

Resharper試用開始

はじめまして。出口と申します。 8月に入社いたしました新人です。よろしくお願いいたします。     早速ですが、JetbrainsのReSharperを導入してみました。 これはVisualStudioをより便利に使えるようにしてくれるアドオンです。 ReShaperと読んでしまっていましたが、ReSharperが正しいようです。危ないところでした。   私は業務ではC#を使うことが多いので、実力のなさをツールで少しでも補完しよう、ついでに今回の記事のネタになればと思い導入しました。 本日は少しだけですが機能の確認を行いました。   とりあえずReSharperに私のコードを見てもらったのですが、リファクタリングできる部分を波線で表示してくれます。 かなり多かったので焦りましたが、修正はクリックするだけで自動でやってくれるので大変便利でした。メッセージもわかりやすいです。   正規表現のチェックができるツールも入っていました。気軽に使えて便利です。 他にもTo-do Explorer(ソリューションからToDoを探してくれます)やLocate in Solution Explorer(閲覧中のファイルをソリューションエクスプローラ上で選択してくれます)など地味ですが便利そうな機能もあるようです。   まだ一日目なので確認できたのはこんなところですが、試用は30日間あるので少しずつ見ていこうと思います。 皆様も是非ReSharper試用してみてください。30日間無料です。   記事中なにか間違いがありましたら教えて頂けると嬉しいです。 ありがとうございました。        

  • シスキュー技術部

Microsoft製品のサポート期限について

noimage

Microsoft製品のサポート期限について

2019年になり、今年以降のMicrosoft製品のサポート期限について確認していきます。 2019年はMS SQL Server2008および2008 R2が7月に延長サポート期限が終了します。 それ以降はセキュリィについての脆弱性が発見されても修正されることはなく、早めのリプレースが必要となります。 2019年に延長サポート期間が終了するメジャーな製品はこれだけのようです。 2020年は激動の年となり、たくさんの製品が延長サポート終了になります。 Windows7が1月、Windows Server2008も1月、Office 2010が10月に延長サポート終了となります。 定期的なWindows Updateが終了し、セキュリティパッチが配布されなくなります。 これに伴って2019年後半はWindows7を搭載したPCのリプレースが大幅に進むことになることが予想され、Windows XP延長サポート終了時のようにPCの入手が難しいくらいの需要増となる見込みがあります。 まだあと一年と考えているうちにPCの入手が難しくなるほどの時期になってしまう恐れがあります。 今年最初にこれからWindows 7PCのリプレースについてであっても遅くはないと思うところです。

  • らずぱいでIoT

らずぱいでIoT 第9回(python版 気温・気圧・湿度計算)

noimage

らずぱいでIoT 第9回(python版 気温・気圧・湿度計算)

今回は、いよいよpython版のレジスタの読取り・計算・表示の全プログラムです。 このプログラムでは、Dict(連想配列)を使う事でチップ説明書にあるレジスタアドレスと一致するように工夫してあります。 プログラムの内容自体は、前回のチップ説明書の中にある保障式を今まで書いてきたプログラムに合うように書き直したものです。 ------------------------------------- 以下ソース #!/usr/bin/python import smbus import time SMBUS_NUMBER = 1 SMBUS_ADDR = 0x77 SMBUS_REG_CONF = 0xF5 SMBUS_REG_CTRL_MEAS = 0xF4 SMBUS_REG_CTRL_HUM = 0xF2 dig_T = {} dig_P = {} dig_H = {} calib = {} n = 0x88 while n <= 0xA1: __ calib[n] = 0 __ n = n + 1 n = 0xE1 while n <= 0xF0: __ calib[n] = 0 __ n = n + 1 n = 0xF7 while n <= 0xFE: __ calib[n] = 0 __ n = n + 1 bus = smbus.SMBus(SMBUS_NUMBER) bus.write_byte_data(SMBUS_ADDR,SMBUS_REG_CONF,0xA0) bus.write_byte_data(SMBUS_ADDR,SMBUS_REG_CTRL_HUM,0x01) bus.write_byte_data(SMBUS_ADDR,SMBUS_REG_CTRL_MEAS,0x25) time.sleep(0.1) for k in calib.keys(): __ calib[k] = bus.read_byte_data(SMBUS_ADDR, k) dig_T[1] = (calib[0x89] << 8 | calib[0x88]) dig_T[2] = (calib[0x8B] << 8 | calib[0x8A]) dig_T[3] = (calib[0x8D] << 8 | calib[0x8C]) dig_P[1] = (calib[0x8F] << 8 | calib[0x8E]) dig_P[2] = (calib[0x91] << 8 | calib[0x90]) dig_P[3] = (calib[0x93] << 8 | calib[0x92]) dig_P[4] = (calib[0x95] << 8 | calib[0x94]) dig_P[5] = (calib[0x97] << 8 | calib[0x96]) dig_P[6] = (calib[0x99] << 8 | calib[0x98]) dig_P[7] = (calib[0x9B] << 8 | calib[0x9A]) dig_P[8] = (calib[0x9D] << 8 | calib[0x9C]) dig_P[9] = (calib[0x9F] << 8 | calib[0x9E]) dig_H[1] = calib[0xA1] dig_H[2] = (calib[0xE2] << 8 | calib[0xE1]) dig_H[3] = (calib[0xE3]) dig_H[4] = (calib[0xE4] << 4 | calib[0xE5] & 0xf) dig_H[5] = (calib[0xE6] << 4 | calib[0xE5] >> 4) dig_H[6] = (calib[0xE7]) for i in [2,3]: __ if (dig_T[i] & 0x8000): ____ dig_T[i] = (-dig_T[i] ^ 0xffff)+1 for i in [2,3,4,5,6,7,8,9]: __ if (dig_P[i] & 0x8000): ____ dig_P[i] = (-dig_P[i] ^ 0xffff)+1 for i in [2,4,5]: __ if (dig_H[i] & 0x8000): ____ dig_H[i] = (-dig_H[i] ^ 0xffff)+1 if (dig_H[6] & 0x80): __ dig_H[6] = (-dig_H[6] ^ 0xff)+1 raw_T = calib[0xFA] << 12 | calib[0xFB] << 4 | calib[0xFC] >> 4 raw_P = calib[0xF7] << 12 | calib[0xF8] << 4 | calib[0xF9] >> 4 raw_H = calib[0xFD] << 8 | calib[0xFE] tv1 = ((raw_T >> 3) - (dig_T[1] << 1)) * (dig_T[2] >> 11) tv2 = (((raw_T >> 4) - dig_T[1]) * ((raw_T >> 4) - dig_T[1])) >> 12 tv2 = (tv2 * dig_T[3]) >> 14 t_fine = tv1 + tv2 Temp = ((t_fine * 5 + 128) >> 8) / 100.0 pv1 = (t_fine / 2.0) - 64000 pv2 = ((pv1 / 4.0) * (pv1 / 4.0) / 2048) * dig_P[6] pv2 = pv2 + ((pv1 * dig_P[5]) * 2.0) pv2 = (pv2 / 4.0) + (dig_P[4] * 65536.0) pv1 = (((dig_P[3] * (((pv1 /4.0) * (pv1 * 4.0)) /8192)) / 8) + ((dig_P[2] * pv1) / 2.0)) / 262144 pv1 = ((32768 + pv1) * dig_P[1]) / 32768 if pv1 != 0: __ p = ((1048576 - raw_P) - (pv2 / 4096)) * 3125 __ if p < 0x80000000: ____ p = (p * 2.0) / pv1 __ else: ____ p = (p / pv1) * 2 __ pv1 = (dig_P[9] * (((p / 8.0) * (p / 8.0)) / 8192.0)) / 4096 __ pv2 = ((p / 4.0) * dig_P[8]) / 8192.0 __ p = p + ((pv1+ pv2 + dig_P[7]) /16.0) else: __ p = 0 Pres = p / 100.0 hv = t_fine - 76800.0 if hv != 0: __ hv = (raw_H - (dig_H[4] * 64.0 + dig_H[5]/16384.0 * hv)) * (dig_H[2] / 65536.0 * (1.0 + dig_H[6] / 67108864.0 * hv * (1.0 + dig_H[3] / 67108864.0 * hv))) __ hv = hv * (1.0 - dig_H[1] * hv / 524288.0) __ if hv > 100.0: ____ hv = 100.0 __ elif hv < 0.0: ____ hv = 0.0 else: __ hv=0.0 Hum = hv print "T=%2.1f P=%4.1f H=%1.2f" % (Temp,Pres,Hum) ------------------------------------- ここまで 尚、_はスペースです。 ソースはこちらからダウンロードできます。  

  • パソコン関連

Windowsにサンドボックス機能が搭載

noimage

Windowsにサンドボックス機能が搭載

Windows10の今後のアップデートでサンドボックスが機能として追加されることが明らかになりました。 サンドボックスは独立したアプリケーションの実行環境で、サンドボックス外のファイルやシステム、メモリに対して影響をおよぼさない仕組みです。 安全性に不安のあるアプリケーションなどもサンドボックスを利用すれば安全に実行することができ、サンドボックスを閉じてしまえばその他への影響を心配せずにアプリケーションを終了できます。 実装としては最低限度の仮想マシンと似た仕組みとなるようです。 スマートフォンもセキュリティのためにほとんどのアプリはサンドボックス上で動作しています。 アプリが操作できるファイルはアプリのサンドボックス内でのみとなっており、他のアプリのファイルやシステム領域を操作できない仕組みです。 Windowsもアプリケーションの実行にサンドボックスを積極的に取り入れていくのかもしれません。 ウィルスなどの危険なものもサンドボックス上で動作を確認するなども可能ではありますが、サンドボックスの仕組みの未知の脆弱性を攻撃する可能性もあります。 そもそもお互い干渉できないはずの仮想サーバーが、他の仮想サーバーを操作するプロセッサーの脆弱性が今年発見されたりなどもありました。 サンドボックスだから何もかも安心ではありませんが、独立した仮想マシンを作ってアプリケーション操作するなどの手間が不要となり、主に開発の分野で役に立ちそうな機能です。

  • ブログ

views を見て

noimage

views を見て

ごろーです。 前回のブログで、 https://www.sys-cube.co.jp/blog/15002.html という記事が自分ブログの中で沢山のアクセス数をゲットしている、という事を書きました。 その後も少しずつアクセス数を伸ばし、1000 viewsを超えてきました\(^o^)/ (いや、何万というアクセス数を稼ぐブログからみれば少ないですが) ただ、喜んでもいられず、 「Xamarin live player、今はTestFlightのβ版すら入手できないのに情報が古いなぁ」 と申し訳なく思いましたので、今から来られる方のためにその旨追記しておきました。   というわけで、最近このブログ内のviewsの数字が気になり、 「システムキューブブログ内で一番アクセス数が多い投稿って何だろう?」 と調べてみたところ。 2013年のしまざき さんの記事 https://www.sys-cube.co.jp/blog/3519.html が87,901 viewsを獲得し、堂々の第一位!でした。 非常に驚いたことに、これを調べた本日(2018/12/19) ひろた さんに聞かれて「TeamViewer Host」をネット検索した際、 「TeamViewer Hostが凄い!」というブログに興味を惹かれ まさにしまざきさんのブログと同じ内容の記事を読んだところでした。 あちらは2016年10月の記事でしたので、 しまざきさんのほうが3年も早くブログネタにしていたことになります。 草分け的なブログは当然、参考に見に来る人が多いですよね!   やはり、皆さんに読んでいただくためには 皆が興味のある話題を、 いち早く、 丁寧な記事にすること。 ですね!

  • ブログ

Windows10にPHPが・・・

noimage

Windows10にPHPが・・・

かわせです。 最近IoTやってます。 で、データ連携してアプリケーションを作っていたらWindowsのパスに C:\Program Files\iis express\PHP\v7.0 こんなところが含まれているのを発見! そういやIISが入っているのでPHPが使えるようになったのか?しかもバージョン7! で試してみました!! やっぱり動いた! 所々、漢字が化けた表示はシフトJISのコマンドプロンプト上でUTF-8が表示されるためですね! ということでWindows10がLinux化してきている!!という話でした。

  • パソコン関連

Windows10のメモ帳のアップデートと文字コード

noimage

Windows10のメモ帳のアップデートと文字コード

Windows10の今後のアップデートで、メモ帳で保存時のデフォルトの符号化方式がUTF-8、BOMなしという形式になります。 UTF-8は国際的な文字コードの規格Unicodeの符号化方式の一つで、従来までのメモ帳でUTF-8を扱う際はBOMありという形式でした。 BOMはバイトオーダーマークの略称で、このテキストUTF-8であることと、エンディアンを認識するために追加される先頭数バイトに付加される情報です。 エンディアンは複数バイトのデータを受け取る時に、バイトの並び順の解釈の方法です。 これまでのメモ帳を利用してUTF-8で保存するときは必ずBOMが先頭に保存される仕様でした。 BOMが付加されるとUTF-8とANSI方式の互換性が失われてしまうという問題がありました。 ANSI形式はアルファベットと数字、標準的な記号で構成され1バイトで表現されます。UTF-8は1バイトで表現できるものは1バイトのままで記述てでき、漢字を含めた多言語を扱う場合は複数バイトを利用して符号化できるのようになっています。 UTF-8はそのANSI形式との互換性があるために多言語での開発に活かされ、Webベースの開発ではデフォルトの符号化方式になっています。英語圏の開発者でもUTF-8を意識して作成しておけば、そのまま多言語対応のソフトウェアにすることができます。 BOMがつくことになると、データを受け取る側がBOMを解釈するという処理を必要とすることになり、その処理を持たないシステムでは文字データとしてうまく扱うことができません。 そのためWeb系での開発ではWindows標準のメモ帳を使わないというルールが設けられることもあるようです。 もともとUTF-8がありふれた形式ではなく、互換性に慎重にならざるを得ない状況で付加されたメモ帳の機能ですが、昨今のUTF-8の利用状況を鑑みてBOMなしが新しいメモ帳の標準の保存形式となるようです。

  • パソコン関連

ブラウザーEdgeがChromiumベースへ移行

noimage

ブラウザーEdgeがChromiumベースへ移行

Windows 10の標準ブラウザーであるEdgeが独自開発のものからオープンソースChromiumをベースにしたものへ移行されることになりました。 ChromiumはGoogle Chromeに利用されているHTMLレンダリングエンジンです。実質的にEdgeとChromeはHTMLやCSS、javascriptなどが互換性を持つことになります。 これによりWEB開発者はEdgeでの検証を今後スキップすることができるようになります。 現在ブラウザシェアはGoogle Chromeが半数以上を占めています。それに対してEdgeは10%に満たないシェアしかありません。それについてMicrosoftが独自のHTMLレンダリングエンジンを開発し続けるコストに意味を見出さなくなったものかと思われます。 今後ChromiumベースのEdgeはWindows7や8.1、macOSなどにも提供されるということです。 Windows7以降でもEdgeが利用できるようになることで、Internet Explorerのシェアに対する影響は不明なところです。 古いブラウザーであるInternet Explorerの存在はWEB開発者にとっては互換性を取るために最も苦心するところですが、ActiveXが動作するなどの条件があり今だに脱却できないシステムなども多くあります。 今回のEdgeの方針転換がWEBブラウザシェアに対してどのような影響を及ぼすのかは今の所不明ですが、現状のChrome優位は動くことはなさそうです。  

  • らずぱいでIoT

らずぱいでIoT 第8回(16Bit幅の補数計算検証)

noimage

らずぱいでIoT 第8回(16Bit幅の補数計算検証)

pythonのint型変数の扱いには少し注意が必要です。 python3のint型は最大のBit幅に制限なくShortやLongといった区別がなくなりました。 そのため前回の16Bit長のレジスタ値のマイナス表現でpythonが認識しているbit幅に拡張する場合どう描くべきかをC言語のプログラムを使い見てみます。 その前に補数について少し触れておくと 計算機内部では、マイナス値がどのように扱われているかという事を見てみると 1Byte=8bit長の2進数で表現可能で計算機内部では5という数字は 00000101 という2進数です。 この5をある数字から引きたい場合、計算機の中でどのようなことが起きるかというとビットを反転させる解くことが起きていますなので5は 11111010 という2進数になりこれを1の補数といいます。 1の補数表現の5にある数字を足すと例えば十進法の10を足すと十進法の10は2進法で 00001010 なので 11111010+00001010 = 100000100 となりますが8bit幅なので最上位の1が無くなり 00000100 = 十進法の4 となります。 上の2進数の式を10進法で見てみると 250 + 10 = 260 で8bitで表される最大数は255なのであふれた分を計算すると5という10-5の答えが得られます。 では1の補数で計算するとなぜ答えが4になるかというと計算機内部で最上位ビットを符号とした場合 2進数の10000000は-0というおかしな値が存在しているためで、この分符号反転した時点で1を足さないとつじつまが合わないということが起きます。このようにビット反転して1を足した補数を2の補数と呼びます。 2の補数で計算してみると 11111011+00001010 = 100000101 となり2進数でも正しい値が出てきます。 これを踏まえた上で、16Bit幅のマイナス値をpythonのint型に拡張する場合どうするかをpythonではBit幅が確定されていないのでC言語で試してみたいと思います。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーー 以下プログラム #include <stdio.h> void main() { unsigned short n = 0xfff5; _______ short m; ____ printf("単純にマイナス %04x->%d(%08x)\n",n,-n,-n); ____ // 16Bit幅で2の補数表現に変換 ____ m=(-n ^ 0xffff)+1; ____ printf("2の補数表現に変換 %08x -> %d\n",m,m); ____ printf("-11のビット確認 %08x -> %d\n",(short)-11,(short)-11); } ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーここまで なお_はスペースを示します。 最初のpirntfではunsigned short(32bit)の変数に0xfff5(16bit)をいれて単純にマイナスに変換すると32Bit幅で2の補数値が計算され0xffff000bとなります。 そのため下位16ビット幅で2の補数を計算してみると 0xfffffff5という値に拡張されていることがわかります。(2番目のprintf) 念のため32Bit長の-11が32bitはばで0xfffffff5であることを確認してみます。(3番目のprintf) ということでpythonで拡張できるかを以下のプログラムで確認してみると ーーーーーーーーーーーーーーーーーーーーーーーーーーーー ここから python #!/usr/bin/python n=0xfff5 print("%x -> %d\n" % (n,(-n ^ 0xffff)+1)) ーーーーーーーーーーーーーーーーーーーーーーーーーーーー ここまで ということで16Bitのマイナス値をPythonの持つ不確定長の整数型に上記の式で拡張できることが検証できます。 今回使用したCのソースとPythonのソースはここからダウンロードできます。  

1 11 12 13 14 15 72