2018年12月14日金曜日

文字コード変換はコマンド一発で解決!



こんにちは。よっしーです。

今日は文字コードについてのお話しをしたいと思います。


今まで、いろいろなプロジェクトに携わってきましたが、

開発環境、実行環境などによって、ソースファイルの文字コードが決まっており、

開発者が文字コードを「意識する」という場面がよくあります。


使用するテキストエディタ、ツール等によるところがありますが、

新規作成したソースファイルを保存する際、デフォルトの文字コードが決まっており、

そのデフォルトの文字コードが、期待する文字コードになっていないと、

知らず知らずのうちに、プロジェクトに沿わない文字コードで

ソースファイルを生成してしまうこととなります。


チームで開発をしていると、ソースファイルを集約したときに、

ファイル毎に文字コードがばらばら。。。なんてことも、よくありますよね。


で、そういったとき、ソースファイルの文字コードを正しいものに「変換」するのですが、

Windows でいろいろと文字コード変換ツールを使ってはみたものの、

あまりしっくりくるものがなく、いろいろと試した結果、Linuxコマンドを

使用して変換する。というスタイルに落ち着きました。


なので、今回は文字コード変換の方法についてご紹介したいと思います。

(例のごとく、Ubuntu環境でのやり方となります)




はじめに、nkf というコマンドを使用しますので、インストールします。

nkf コマンドをインストール
$ apt-get install nkf


あとは、いろいろなコマンドとを組み合わせて使います。

まずは、現在のファイルがどのような文字コードになっているかを確認してみましょう。


複数ファイルの文字コードをコマンド一発で確認
$ find . -type f | xargs nkf --guess | column -s: -t

出力結果
↓ファイル文字コード
./inc/client_recv.hUTF-8 (BOM) (LF)
./inc/client_send.hUTF-8 (BOM) (LF)
./inc/main.h       UTF-8 (BOM) (CRLF)
./inc/svc_recv.h   Shift_JIS (CRLF)
./inc/svc_send.h   Shift_JIS (CRLF)
./src/client_recv.cUTF-8 (LF)
./src/client_send.cUTF-8 (LF)
./src/main.c       UTF-8 (BOM) (CRLF)
./src/svc_recv.c   Shift_JIS (CRLF)
./src/svc_send.c   Shift_JIS (CRLF)

ファイルによって文字コードや改行コードがバラバラですね。。。


で、これを1つの文字コードに統一するため、変換をかけます。

複数ファイルの文字コードをコマンド一発で変換

※ Shift-JIS、改行コード=CR+LF にする場合
$ find . -type f | xargs nkf --overwrite -s -Lw

※ UTF-8、改行コード=LF にする場合
$ find . -type f | xargs nkf --overwrite --oc=UTF-8 -Lu

※ UTF-8(BOM付)、改行コード=LF にする場合
find . -type f | xargs nkf --overwrite --oc=UTF-8-BOM -Lu



UTF-8、改行コード=LF の変換をかけた後、文字コード確認をしてみると、、、

出力結果
./src/client_recv.cUTF-8 (LF)
./src/client_send.cUTF-8 (LF)
./src/main.c       UTF-8 (LF)
./src/svc_recv.c   UTF-8 (LF)
./src/svc_send.c   UTF-8 (LF)
./inc/client_recv.hUTF-8 (LF)
./inc/client_send.hUTF-8 (LF)
./inc/main.h       UTF-8 (LF)
./inc/svc_recv.h   UTF-8 (LF)
./inc/svc_send.h   UTF-8 (LF)
キレイに文字コードがそろってますね!


ファイルをテキストエディタで開いて、文字コードを指定し保存する。

というやり方でもよいですが、ファイルの数が多くなってくると、

かなり手間になってしまうので、そんな時はコマンド一発で一気にやってしまいましょう!


ではまた~。

2018年12月7日金曜日

ExcelでF1を押してもヘルプが出ないように



こんにちは、ふじかーです。

先日「Excelがもっと捗る小技」をいくつか紹介しましたが
ひとつ大事なのを忘れてました。


誤って F1 を押したときに出るヘルプがうざい


もっとも不要と思われるキー「F1」

大人気の主要キーである「F2」「ESC」の間に隠れて、自分も押下されるのを待ち続け
ついブラインドタッチミスで押されようもんなら

お前は必要ない

と見たくもないのに最前面に姿を現し、しかも重くイラッとさせられる。
そんな経験、誰しもあるんじゃないでしょうか。

このF1ヘルプ、周りで使っている人見たことありません。
私も活用したこと無いですし、あなたもおそらく無いでしょう。

皆これには辟易としているようで、
こいつを出なくする方法を検索するとたくさん出てきます。

 キーボードのF1キーを抜く
 F1ブレイカーというアプリを入れておく
 レジストリを書き換える
 マクロを利用する

などなど。
①②③ はちょっと過激なので をチョイスします。

マクロでの対処方法をググってみると
「個人用マクロブックを使う」という記事が多いようです。


「個人用マクロブック」とは
マクロの記録画面で選択できる保存先の一つなんですが

これは、一度使うと「PERSONAL.XLSB」というブックが生成され、それ以降
Excelの起動と同時に、こいつも背後でこっそりと自動的に開かれるようになります。

一応これを使っても実現可能なんですが、
これだとExcelを同時に複数、別ウィンドウで開いた時に

と出るようになり、これはこれでイラッとするので却下。


私は「アドインとしてマクロを組み込んでやる」方向で対応しました。


対策方法


対応の流れは
 1.ExcelファイルOpen時にF1を無効にするVBAマクロを書く
 2.マクロをアドインとして保存する
 3.アドインを有効化
という感じ。


1.ExcelファイルOpen時にF1を無効にするVBAマクロを書く
・Excelを新規に開き、
・Alt+F11を押下してVBEditorを開いて、
・ThisWorkbookをダブルクリックして開き
・下記のコードを貼り付ける

Private Sub Workbook_Open()

    Application.OnKey "{F1}", ""

End Sub
・VBEditorを閉じる



2.マクロをアドインとして保存する
・「名前を付けて保存」画面を開き、
・ファイルの種類で「Excelアドイン(*.xlam)」を選択
・勝手にアドインフォルダが開かれるので
・適当に名前を付けて保存(ここでは 「F1ヘルプ無効化」 にします)





3.アドインを有効化
・Excelを表示した状態で 「Alt」「T」「O」 と順番に押下し、Excelのオプション画面を開く
・アドイン → 設定(G) をクリック
・上で作成した F1ヘルプ無効化 にチェックをいれて、OKで閉じる
・Excelを一度閉じる






以上、終了です。これでもう、あの大嫌いだったF1ヘルプは
どれだけプッシュしようが出てこなくなりました。少し寂しいくらい。

同じようなストレスを抱えてる方がいれば、参考にして下さいな。

2018年11月30日金曜日

Googleレンズが意外と便利!? 風景から場所を特定したり、画像に写ったモノの名前を教えてくれたりするぞ!!



こんにちは。よっしーです。

私が使っているスマホ、zenfone5 なんですが

「Googleレンズ」に対応。というニュースを最近見つけたので、

これは!?と思い、さっそく使ってみました。

面白くて便利なので、紹介したいと思います。


「Googleレンズ」の起動はカメラアプリ上から行えます。

zenfone5だと、カメラを起動すると左下に「Googleレンズ」の
アイコンが追加されていました。


アイコンを選択すると、画面タップを促すメッセージが出力され・・・


タップすると、カメラに写った画像から、その被写体が何かを解析してくれます。


Googleレンズで出来ることは以下になります。

1.画面に写っている文字を認識し、テキストデータとしてコピー
2.画面に写っている被写体の類似商品の検索
3.画面に写っている動物や植物の特定
4.画面に写っている本、メディアの特定
5.バーコードのスキャン

これらは、写ったものによって自動的に判断されるようです。
どんな結果になるか、いろいろと写して試してみました。


神戸の夜景で試したところ、ポートタワーをちゃんと認識しました。


似たような形なんていっぱいありそうな神社でしたが、
ちゃんと湊川神社と認識してくれました。すごい!!


そこらへんに生えてた花も、名前がちゃんと出てきました。


スナック菓子もちゃんと出てきますし、多少でこぼこしていても、英語をテキストと認識しています。


ちょっと特定の難しいものだったりすると、こんな感じで候補がいくつか出てきます。


見当違いの結果が出てくることもあったりで、

精度はそこまで高くないのですが、なかなか面白い機能ですよね。

また、画像を指定して解析することもできるので、

例えば、先日行った城崎の社員旅行の画像なんかを指定してみると、、、


類似画像で「城崎」という地名が出てきていることも確認できました。


撮りためている写真なんかをみて、これどこ行ったときの写真だっけ???

というようなことがあれば、一度Googleレンズに解析させてみると、

案外特定してくれたりするかもしれませんよ。


ではまた~。

2018年11月23日金曜日

DNSを「1.1.1.1」にして、更にネットをセキュア&高速化・・・!


こんにちは、ふじかーです。

先週の記事で「寝室でも快適にインターネット」できるようにしましたが
それに引き続き、ネットのアクセス速度の改善ネタ をもう一件。

DNSを変えて高速化を図る


「1.1.1.1」というサービスをご存知でしょうか。
Cloudflare という企業が提供する DNSサービス です。

  • DNS(DomainNameSystem)
ご存知、URLとIPアドレスを変換する仕組ですね。
例えば、yahooを開く場合「www.yahoo.co.jp」というURLを入力しますが
ネット上では「183.79.135.206」というグローバルIPアドレスでアクセスされています。
(実際、http://183.79.135.206 と入力しても正しく表示できる。)

このアドレス変換をするサーバが DNSサーバ。
ここの応答速度もパフォーマンスに影響があるようです。
IPアドレスの設定画面の下の方にあるアレ。

  •  DNSサービス提供企業
「そんなとこ自動設定だよ。気にしたことねーよ。」
という方が多いかも知れませんが、

Google や Cloudflare など、いくつかの企業がDNSサービスを展開しており
設定変更すると「レスポンス速度の向上」「セキュリティの向上」などが期待できるようです。
■Cloudflare
優先DNSサーバのアドレス 1.1.1.1
代替DNSサーバのアドレス 1.0.0.1

■Google
優先DNSサーバのアドレス 8.8.8.8
代替DNSサーバのアドレス 8.8.4.4
覚えやすいですね。


  • セキュリティ
自動取得だと、たぶんネット回線を提供しているプロバイダが用意した
DNSサーバが利用されると思います。

まぁおそらく日本のプロバイダは大丈夫と思うんですが、
フリーwifi や 安心できない国のプロバイダ では
インターネット閲覧状況に関するデータを販売したり、
そのデータを基に広告を送りつけてきたりする事もあるとか。

上記の企業のDNSは「そんな心配は無く安心ですよ」と言っているようです。


  • アクセス速度
またGoogle / Cloudflare ともに「レスポンス速度」も売りにしているようですが
現状は Cloudflare の「1.1.1.1」が圧勝の模様。


この「1.1.1.1」、2018年の4月くらいにサービス開始しましたが
 DNS設定するだけで、インターネットのセキュリティーが向上し、
 さらにインターネットの速度が爆速になる!
と話題になっていたようです。


1.1.1.1アプリがリリース


そんなCloudflareから、1.1.1.1のスマホアプリが
2018/11/11 にリリースされたとの事。

1.1.1.1: Faster Internet
1.1.1.1: Faster Internet
開発元:Cloudflare
 無料 posted withアプリーチ

さっそく試してみました。

インストールは簡単。
「どれどれ、爆速なったかな?」
と、wifi-on状態でスピードテストサイトで速度比較したところ
1.1.1.1 設定OFF・・・ダウンロード170Mbps アップロード220Mbps
1.1.1.1 設定ON ・・・ダウンロード170Mbps アップロード200Mbps
あれ・・・全然変わんない。 wifi-offにしても高速化は見られない。
「効いてんのかコレ?」と思い調べた所、それもその筈。

DNSの変更は
「Webページの表示を高速化」
とは言うものの、
「ファイルのダウンロードが早くなるというものでは無い」
のでした。

Webページ内に画像などが多数あり、たくさんのURLが振られていれば
それぞれ高速にアドレス変換してアクセスできるので
「ちりつも」でページの表示速度が早くなるようです。

確かに1ファイルのダウンロード、「URL→IPアドレスの変換」は1回したら終わりですもんね。
その後のダウンロード速度を上げたければ、回線を高速化するしかありません。

ちょっと今回のは爆速を体感できるものではありませんでしたが
フリーwifiとか「少しセキュリティ気を付けたいな」てな時に良いかも知れません。

興味がある方は、試してみて下さいな。

2018年11月16日金曜日

どの階でも快適無線LAN・・・!


こんにちは、ふじかーです。

我が家では二階のリビングに無線LANルータを置いているのですが

寝室は三階にあるため
「寝ながらスマホ」する時に電波が悪くてイラッとします。
さっきまで辛うじて繋がっていたのに
ふとしたタイミングで、ロード中の くるくるくるくる が止まらない。

仕方ないのでスマホのWifiをOFFにしてLTE回線で更新したり・・・
そんな地味なストレスに限界がきて、対策した時のお話。


ルータ設置の注意


繋がりにくい場合、下記のような点に気を付ければよいそうです。

  • 電波の強いルータを選ぶ
  • 障害物を避ける
  • 水槽など、水の近くは避ける
  • ルータは高い位置に置く
  • 電子機器の近くは避ける

障害物があると入りにくい、なんてことは誰でも想像つきますが

「電波は水が苦手」
「電波はアンテナから横下方向に飛ぶ」

てのはあまり知られてないかもしれません。

基本的に水平方向へ飛んでいくようです
なので同一階の高い位置に・・・
ってルータが下の階にある時点で無理(´・ω・`)


使用する電波を選ぶ


最近のルータの電波帯域には「2.4GHz」「5GHz」の二種類があり
どちらでつなぐか、接続端末側から選べるようになってます。
  • 2.4GHz
○ 障害物(壁や床など)に強く、電波が遠くまで届きやすい
× 無線LAN以外の多種多様な製品で使われており、干渉しやすい
× 通信速度は遅め

  • 5GHz
○ 通信速度が速い
○ 基本的に無線LANにしか使われていないので干渉しにくい
× 障害物に弱く、距離が遠くなると電波が弱くなる
× 古いルータは対応していなかったりする

という特徴があります。

階が違うため 5GHz は期待できないので、2.4GHz を選択してみたものの・・・

冒頭に書いているように
繋がったり途切れたりで安定しません(´・ω・`)


中継器をつかう


無線LANの電波が届きにくいとき、
改善手段として「中継器」というのがあります。

無線LANルータからの電波をうけて、中継器自体から増幅して発信する というもので
安いもので3000円くらいから売っているみたいです。
BUFFALO の 中継機 WEX-733DHP 
設置位置は当然「ルータからの電波が充分に届く」必要があります。
あと、コンセントも必要。

廊下とか階段とか? そんな都合の良い場所あるかな・・(´・ω・`)

とりあえず、試しに購入して設置場所探してみるか~ と思ってたのですが・・・


無線LANルータを増やす


これまで何度かルータを買い替えてきたので
あまっている無線LANルータが家にありました。

これ使えないのかなーと調べると、いっぱい出てきました。

気を付ける点としては・・
  • アクセスポイントモード設定
ブリッジモードと言われたりもしますが、最近の無線LANルータには
大体こんな設定があるようです。家に余っているルータにもありました。

ルータとしての機能(ネット接続やIP割り当て等)を殺して、
無線LAN電波塔としてのみ使うわけですね。

  • 有線でつなぐ必要がある
上の階までLANケーブルを配線する必要があります。


通常なら「配線はちょっと面倒くさいなぁ~」と思うところですが、以前
上の階にサーバ機を置くため、階段の天井沿いにLANケーブルを這わせていたのでした。

これに旧機種ルータをつないで、アクセスポイントモードに切り替えることで
寝室も 快適無線LAN環境 となりました。

同じようなストレスを抱えてる方がいれば、参考にして下さいな。

2018年11月9日金曜日

C#(.NET Framework)で作ったコンソールアプリを .NET Core を使ってLinuxで動かしてみる!【後編】


こんにちは。よっしーです。

今回は、Visual Studio 2017 の C#(.NET Framework)で作ったコンソールアプリを
.NET Core を使ってLinux上で動かす。という前回からの続きです。

まず、Linux(Ubuntu)へ .NET Core をインストールします。
(現在最新バージョンの .NET Core 2.1 を入れます)

公式サイト(https://dotnet.github.io/)にディストリビューションごとの
インストール手順が記載されていますので参考にして下さい。

私の手元には Ubuntu14.04 があったので、今回はそこへインストールしました。

Microsoftのキーとフィードを登録

$ wget -q https://packages.microsoft.com/config/ubuntu/14.04/packages-microsoft-prod.deb
$ sudo dpkg -i packages-microsoft-prod.deb

.NET Core をインストール
※ 公式サイトの手順は、sdkをインストールしていますが、
今回は実行環境のみインストールしたいので、runtimeをインストールしています。

$ sudo apt-get install apt-transport-https
$ sudo apt-get update
$ sudo apt-get install dotnet-runtime-2.1

これで実行環境が用意できました。

あとは、前回 Visual Studio で作成した、
実行ファイル一式を、Linux上へ配置します。

$ tree
.
|-- dotnet_sample.deps.json
|-- dotnet_sample.dll
|-- dotnet_sample.pdb
`-- dotnet_sample.runtimeconfig.json

これで準備完了です。さっそく実行してみましょう。
dotnet コマンドにDLLファイルをパラメータとして渡して実行します。

$ dotnet dotnet_sample.dll コマンドライン引数A コマンドライン引数B
コマンドライン引数A, コマンドライン引数B
/home/yossy/dotnet_sample

コマンドライン引数とカレントディレクトリのパスを表示し、
text.txt を出力しています。内容を覗いてみると。。。

$ cat test.txt
コマンドライン引数A
コマンドライン引数B

コマンドライン引数として渡した文字列が正しく格納されています。

Windowsで確認した動作と同じ結果となりましたね。
Linux上で.NET Framework を用いたプログラムが動作していることがわかります。




今回、簡単なサンプルプログラムを作ってみましたが、注意する点として、
WindowsとLinuxではパスの扱いが異なる。ということが挙げられます。

例えばディレクトリ階層を "¥¥" で連結しているようなプログラムは、
Windows側だと正しく動きますが、Linux側ではパス異常となります。

× Windows側でしか正しいパスにならない。
string path = Directory.GetCurrentDirectory() + "\\" + "test.txt";

 パス結合するライブラリを用いることでWindows/Linux共通で動作する
string path = Path.Combine(Directory.GetCurrentDirectory(),"test.txt")



OSに依存するような所はライブラリが吸収してくれるはずですので、
上手くそれらを使うようなプログラミングを心がけましょう。

ではまた~。

2018年11月3日土曜日

C#(.NET Framework)で作ったコンソールアプリを .NET Core を使ってLinuxで動かしてみる!【前編】


こんにちは。よっしーです。


さて今回は、タイトルにもある通り、

C#(.NET Framework)で作ったコンソールアプリをLinux上で動かす。

ということをご紹介したいと思います。


.NET Framework って Microsoft が提供してるから、

.NET Framework = Windows というイメージがありますが、

最近ではLinux上でも動作することが出来るんです。


さっそく Visual Studio 2017 Community でチャレンジしてみましょう。


プロジェクトの作成画面から以下を選択します。
 → Visual C#
  → .NET Core
   → コンソール アプリ(.NET Core)


実行すると 「Hello World!」 と出力されるテンプレートが作成されます。


今回は、.NET Framework が Linux上で動作するかを確かめたいので、
Systemのクラスライブラリを使って簡単なサンプルを組んでみました。

<内容>
・カレントディレクトリパスを取得
・コマンドライン引数とカレントディレクトリ名をコンソール出力
・カレントディレクトリにtest.txtを作成し、コマンドライン引数の内容をそのファイルへ出力


あとは、適当に Visual Studio 上から実行する際のコマンドライン引数と、
作業するディレクトリ(カレントディレクトリ)を情報として設定します。


Visual Studio上で実行してみましょう。もちろんWindows上で動作します。

動作結果として、
設定したコマンドライン引数とカレントディレクトリパスがターミナル上に出力され、
出力された test.txt にはコマンドライン引数の内容が出力されます。

まぁ、実装通りですね。。。


下準備はここまでです。

で、このプログラムを Linux 上で動作させるのが今回の目的となりますので、

次に進めていきましょう。


ビルドメニューから、○○○○(プロジェクト名) の発行 というのがあるので選択します。


次の画面に進むので、続けて 発行 を選択します。


すると、対象のディレクトリに以下のような生成物が出力されます。


DLLファイルが出力されていることがわかりますが、これが Linux上 で動作する
プログラムファイルとなります。

DLLなのに実行ファイル?と、Windows脳だとちょっとシックリこないのですが、
Linux で動作させる場合は、dotnet という実行ファイルに このDLLファイルを
指定して動作させるので、そんなに違和感は感じなくなります。

次は Linux 側での操作となりますが、ちょっと説明も長くなってきたので、
今回はここまでとさせてもらいます。

ではまた~。

2018年10月26日金曜日

Visual Studio Code でC言語をステップ実行

こんにちは、ふじかーです。

C言語をテキストエディタで書いているような 組み込み開発現場 では

(´-`)。oO( このロジックが意図通り動作するか、ちょいと手元で確認したい。。 )

みたいな時、少し困ります。

テキストエディタではそんな事できないし
VisualStudioの無償版は昔に比べて準備も大変だし、使うのも重いし不便。
業務のクロスコンパイル環境を立ち上げるのは、もっと大袈裟で面倒くさい。

ということで「軽量なツールで、C言語をお手軽にステップ実行できる環境」 を作成します。

以前、もりもり君が「なかなか使いやすいっスよ」とお勧めしてくれた
Visual Studio Code(以下、VS Code)を使います。

<手順>



コンパイラ(gcc)をインストール

  • ダウンロード・インストール
下記のサイトにアクセスし、一式おとしてインストールします。
http://www.mingw.org/download/installer
 → mingw-get-setup.exe のダウンロードが始まる
 → 実行して Install → Continue で進める
 → 「MinGW Installation Manager」が起動

  • gcc設定
C言語作業に必要なパッケージをインストールします。
 ・「mingw32-base」   を右クリックして「Mark for Installation」を選択し、チェックを入れる
 ・「mingw32-gcc-g++」を右クリックして「Mark for Installation」を選択し、チェックを入れる
 ・[Installation]→[Apply Changes]]→[Apply]→ セットアップが終われば [Close]


  • パスを通す
システムのプロパティから、環境変数のPathにgccのパスを追加します。
手順が分からない場合、下記参照。
 ・Windowsキー+R → [ファイル名を指定して実行] 画面が開く
 ・「sysdm.cpl」 と入力してEnter → [システムのプロパティ]画面が開く
 ・[詳細設定]タブ → 環境変数(N) → システム環境変数(S) エリアの 「Path」 を選択 → 編集(I)... をクリック
 ・[システム変数の編集] ダイアログの [変数値(V)] の末尾に 「;C:\MinGW\bin」 を追記して [OK]



VS Code 本体をインストール

  • ダウンロード・インストール
下記のサイトにアクセスして、本体をダウンロード・インストールする。
 https://code.visualstudio.com/Download


 → 64bit環境なら、[User Installer 64 bit] をクリック
 → VSCodeUserSetup-x64-X.XX.X.exe のダウンロードが始まる
   (記載時点ではVSCodeUserSetup-x64-1.28.2.exe)
 → 同意して、次へ次へ~でインストール完了。



  • 日本語化 
VS Code はバージョン1.25以降「デフォルト英語版のみ」になったため、
日本語化する必要があります。
 ・画面左の 拡張機能(Extensions)ボタン を押して「Japanese Language Pack」で検索 → Install → VS Codeを再起動



  • C/C++
C/C++開発用の拡張機能もインストールしておきます。
 ・こちらも拡張機能から「C/C++」で検索 → Install → VS Codeを再起動




作業場所、test.cの準備

  • test.c ファイル準備
VS Code からでも お手持ちのエディタでも良いですが、適当にHelloWorldソースを用意します。
#include <stdio.h>

int main(int argc, char *args[])
{
    printf("Hello, world!\n");
    return 0;
}
これを作業フォルダに保存しておきます(ここでは D:\test\test.c )。
またこの作業フォルダを、VS Code のメニューから開いておきましょう。
・メニュー → フォルダーを開く → D:\test



デバッグの為の設定

  • ビルドタスクの設定(tasks.json)
 修正したソースコードをビルドするための設定を行います。
 ・フォルダーを開いている状態で Ctrl+Shift+B
 ・「実行するビルドタスクがありません。ビルドタスクを構成する」というメッセージが出るのでクリック
 ・「テンプレートからtask.jsonを作成する」というメッセージが出るのでクリック
 ・表示された候補の中から「Others 任意の外部コマンドを実行する例」を選択
  → 作業フォルダ内に「.vscode/tasks.json」ファイルが自動生成され、画面に表示される


 ・表示された task.json の
"command": "echo Hello"
  を削除して、下記を挿入
"command": "gcc -g -O0 -o a.exe test.c",
"problemMatcher": "$tsc", 
"group": {
    "kind": "build",
    "isDefault": true
}
 ・Ctrl+S で保存しておく


  • デバッグ環境の設定(launch.json)
 デバッグに必要な設定を行います。
 ・画面左のデバッグアイコンを押下
 ・デバッグの開始アイコン(再生マーク)を押下
 ・表示された候補の中から「C++(GDB/LLDB)」を選択
  → 作業フォルダ内に「.vscode/launch.json」ファイルが自動生成され、画面に表示される


 ・表示された launch.json の
"program": "enter program name, for example ${workspaceFolder}/a.exe",
"miDebuggerPath": "/path/to/gdb",
  を削除して、下記を挿入
"program": "${workspaceRoot}/a.exe",
"miDebuggerPath": "c:\\mingw\\bin\\gdb.exe",
 ・Ctrl+S で保存しておく



デバッグ開始!


 ・試したいコードをmain関数に記載し、リビルドは Ctrl+Shift+B
 ・ブレークポイントをセットしてF5でデバッグ開始、F10でステップ実行


[デバッグの為の設定] を見ての通り、
 gcc を使って test.c を a.exe にビルドして、gdb を使ってデバッグする
というだけのシンプルな構成です。

既存のプロジェクト全体をデバッグするものでは無いけど、軽量だしIntelliSenceも使えるし、
ちょっと机上じゃ面倒な確認をしたい時とか、関数の単体試験などにも使えて便利。

とりあえず現場でも使ってるC環境の手順が整ったので
今度は別の言語も使えるように整備していこう。

※VS Codeは結構な頻度でバージョンアップを繰り返しており
 記事の内容(ver.1.28.2)と 最新のVS Codeとでは、手順や表示が若干異なるかも知れません。

※ちなみに「用意したcソースの日本語が文字化けするよー」という時は
 画面下の文字コード選択からポチポチと選べば直せます。
 

2018年10月19日金曜日

Pythonでつまづいたことを細々とまとめてみる



こんにちは。よっしーです。

この1年ぐらい Python をちょいちょいとさわってきたのですが、
つまづいたところがいくつかあったので、備忘録としてまとめたいと思います。


・Pythonバージョンの 2.x系 と 3.x系 でコードの記法が違う。

 # 2.x 系の標準出力コード
  print 'hogehoge'

 # 3.x 系の標準出力コード
  print('hogehoge')

↑は代表例ですが、その他にもいろいろと書式が変わっています。

2.x系 で書かれたコードを、3.x環境で実行すると、実行時にエラーとなる。逆もまたしかり。
せめて下位verの互換ぐらいはして欲しかった。。。

conda(コンダ)などを使って、2.x系 と 3.x系 の環境切り替えも可能ですが、
2.x系 のサポートは2020年までなので、私は新しい 3.x系 でコードを組むことにしています。


・Ubuntu14.04/16.04 は 2.x系 がデフォルト設定となっている。

 # pythonのパスを表示
 $ which python
 /usr/bin/python

 # python のリンク先を表示(ver2.7を指している)
 $ ls -la /usr/bin/python
 lrwxrwxrwx 1 root root 9 12月 21  2013 /usr/bin/python -> python2.7

これ。ミソなのは、3.x系 も存在しているということ。

 $ ls -la /usr/bin/python*
 lrwxrwxrwx 1 root root       9 12月 21  2013 /usr/bin/python -> python2.7
 lrwxrwxrwx 1 root root       9 12月 21  2013 /usr/bin/python2 -> python2.7
 -rwxr-xr-x 1 root root 3341384 10月 27  2016 /usr/bin/python2.7
 lrwxrwxrwx 1 root root       9  3月 23  2014 /usr/bin/python3 -> python3.4
 -rwxr-xr-x 2 root root 3693624 11月 17  2016 /usr/bin/python3.4
 -rwxr-xr-x 2 root root 3693624 11月 17  2016 /usr/bin/python3.4m

/usr/bin/python のリンクを 3.x系 張り替えるとこで、3.x系 を使うことも可能です。

ただ、/usr/bin/python のリンクが 2.x なのか 3.x なのかに依存したくないので、
私は、実行する際のコマンドを明示的に python3 にするようにしています。

 # この指定だと、python の指しているリンクが 2.x なのか 3.x なのかによって実行エラーとなってしまう。
 python hoge.py

 # この指定だと、必ず 3.x で実行される
 python3 hoge.py


・辞書はとても便利。でも 3.6 以前だと入れた順にソートしてくれない。

 # 辞書に対して、
 dict = {}

 # 値を入れていく
 dict['one'] = 1
 dict['two'] = 2
 dict['three'] = 3
 dict['four'] = 4
 dict['five'] = 5

 # でも表示すると入れた順に並んでいない。
 print(dict)
 {'four': 4, 'three': 3, 'five': 5, 'two': 2, 'one': 1}

これ、3.6以降だと入れた順に並んでいるので、
自分の環境(3.7)では正しく動いているのに、
実環境(3.4)ではおかしな動きになる。ということがありました。

気付くまでにかなり時間がかかりました。

対応としては、OrderedDict(順序付辞書)を用いて回避しました。

 # 順序付辞書に対して、
 from collections import OrderedDict
 dict = OrderedDict()

 # 値を入れていく
 dict['one'] = 1
 dict['two'] = 2
 dict['three'] = 3
 dict['four'] = 4
 dict['five'] = 5

 # きちんと入れた順に並んでいる。
 print(dict)
 OrderedDict([('one', 1), ('two', 2), ('three', 3), ('four', 4), ('five', 5)])


Python は Ver依存でいろいろと問題があるなぁ~。
というのが正直な感想ですね。。。

ではまた~。