読者です 読者をやめる 読者になる 読者になる

Qstairs

起業に向けた活動、およびAndroid・画像認識(人工知能、Deep Learning等)の技術を紹介します

広告

【C++】数値を3文字ごとに「,(カンマ)」区切りする方法

f:id:qstairs:20160601221351j:plain

はじめに

数値の桁をわかりやすくするために、
3文字ごとに「,」区切りしたい時があります。

そこで、今回はC++での
数値を3文字ごとに「,」区切りする方法
について紹介します。
#今回紹介する方法以外に色々なやり方があります。

※今回は負の値は考慮していません。



ソースコードと結果

ソースコードは以下になります。
文字列を更新して3文字以下になるまでループしているのが肝ですね。

#include <string>
#include <iostream>

using namespace std;

int main()
{
  int val = 1234567890;

  string str = to_string(val);  // 数値をstring型に変換
  string dst = "";  // 出力
  while (str.length() > 3) {  // 「,」をつける必要があるまでループ
    dst = "," + str.substr(str.length() - 3, 3) + dst;  // 3文字ごとに「,」で区切る
    str = str.substr(0, str.length() - 3);  // 文字列を更新
  }
  dst = str + dst;  // 最後に「,」をつける必要がない文字列と結合する
  
  cout << val << " -> " << dst << endl;

  return 0;
}

結果は以下になります。

1234567890 -> 1,234,567,890

最後に

今回は
数値を3文字ごとに「,」区切りする方法
について紹介しました。

結構シンプルなソースで実現できたので、
個人的には納得しています。

【IT】痴漢冤罪 IT活用による解決策はないのか

f:id:qstairs:20170516192839j:plain

痴漢を宣告された男性が線路内を逃走するということが最近とても注目されています。

痴漢を疑われたらほぼ間違いなく逮捕されるのが現状です。

映画「それでもボクはやってない」をかなり昔に観ましたが、
今でも覚えているぐらい衝撃的でした。
いつ自分が同じ状況になるかわかりません。

あらぬ疑いをかけられないようにするのはもちろんですが、
疑われたときにどうしようもないため、
逃げたほうが良いというのを聞いたことがあります。
その情報によって線路内逃走が起きたのでしょう。

そして、5月15日
東急田園都市線青葉台駅で痴漢を申告された男性が線路内に飛び降り、
列車にはねられ死亡する事故が起こりました。

今回の男性が実際に痴漢をしたかどうかはわかりませんが、
電車に乗る限り何もしていなくても痴漢を宣告される可能性はゼロではありません。

そこで、どうしたら痴漢冤罪にならずに済むのか考えてみました。



組織にやってほしいこと

・満員電車をなくす
 長年満員電車が続いていていまだ解決できていない。つまり難しい。
男性専用車両を設置
 現実的だが、鉄道会社はニーズがないと考えている模様...
男性専用車両、なぜないの? 女性専用82路線、男性「ゼロ」の理由 - withnews(ウィズニュース)

個人でできること

・電車に乗らない
 無理です。
両手を上げる
 しかし、証拠がないといわれるとどうしようもない
 そこで、スマートウォッチとスマートフォンの加速度センサーの数値を証拠に手を挙げていたことを証明!★IT活用

でも、手を上げてただけでは完全ではありません。

近いだけで疑われる可能性がある
⇒スペースを作る必要がある
厚みのあるリュックを体の前に持ってくる

息を吹きかけるだけでアウトな場合もある
上を向こう

つまり、こうなる

f:id:qstairs:20170516191612p:plain

これを「絶対紳士のポーズ」と名付けます。

最後に

IT活用と言いながら
スマートウォッチとスマートフォン の加速度センサーを使うことしか
私には考え付きませんでした...

そもそも痴漢が起こらなければ痴漢冤罪もありません。
しかし、時すでに遅し。
痴漢による被害が出ています。

こうなってしまった以上、自分の身は自分で守らねばなりません。
明日は我が身と考えて「紳士のポーズ」で頑張りましょう!

【IT】指静脈認証vs顔認証 ~ウォークスルーの戦い~

f:id:qstairs:20170511191637j:plain

日立が東京・大森にあるオフィスに、指静脈による認証で入退館を管理するゲートを設置。歩きながら指をかざすだけで正確な本人確認をする実証実験を行っている。

www.itmedia.co.jp

いつの日か、Suicaの代わりに「手」をかざして、改札やレジを止まらずに抜けていくようになるのか。

個人的には
私のズボンの右ポケットに常に待機しているスマートな奴
があれば事足りる気がします。

とはいえ、女性はスマホをカバンに入れていたり、
年配の方はスマホを持っていなかったりするので、
ニーズはあるのでしょう。

ということで、
指静脈認証と顔認証について考えてみました。



指静脈認証と顔認証のメリット・デメリット

メリット

  • 指静脈認証
    • プライバシーの抵抗が低い
    • 屋内外問わずに使える
  • 顔認証
    • 写真さえあれば使える
    • 動作がいらない

デメリット

  • 指静脈認証
    • 登録のハードルが高い
  • 顔認証
    • プライバシーの側面で利用者の抵抗あり
    • 環境光の影響を受けやすい


上記の環境光に関して、
私も以前勤めていた会社では行動解析システムの開発でIPカメラを使用していたので痛いほどわかります。
日照変動や照明変動で見え方がかなり変化するので、
ほんとに頭を悩ませます(-_-;
行動解析ほどではないでしょうが、顔認証もかなり影響を受けることでしょう。

また、どのメーカーのカメラを使うかで若干の精度差が発生するため、
カメラ選びも難しいところです。
常にカメラも進化しているので、
同じメーカーでも見え方に変化が出てきます...



果たしてどちらに軍配が上がるのか

屋外であれば今のところ指静脈認証かな
と個人的には考えています。

以上

【読書】2017年4月に読み終えた本

f:id:qstairs:20160817231706j:plain

はじめに

4月からフリーランスとなり、残業も0時間になったこともあり、
これまでにまして本を読める時間がとれるようになりました。

せっかくなので1冊ずつ細かく紹介しよう!

と思いましたが、
大変なので一覧で紹介させていただきます...(^_^;

本の紹介

〈インターネット〉の次に来るもの 未来を決める12の法則
 これまでに世界にブレークスルーをもたらしたインターネット。
 では次に何が世の中を変えるのか、未来を決める12の法則をまとめている。
 ここまで広い視野で考察し、まとめているのはただただすごいの一言。
 ただし、長い...


自分を100%好きになるシンプルな習慣 小さなことからあなたが変わる!
 統計データや学術的証拠があるわけではありませんが、前向きになれる言葉が並ぶ本。
 落ち込んだ時にさらっと読むと良さそう。
 女性目線で書かれているので、どちらかというと女性におすすめ。


スティーブ・ジョブズ 驚異のプレゼン
 スティーブ・ジョブズのプレゼンを解析し、なぜ人々を魅了できるのかを解説。
 さらに、プレゼンの天才と呼ばれたスティーブ・ジョブズも実は超努力家だったことが分かる本。


起業家のためのマーケティングバイブル
 起業家にとって最も大切な価値観が書かれている本。
 今売れているサービスを例にしているためイメージしやすい。


なぜ、残業はなくならないのか(祥伝社新書)
 電通過労自死事件でより注目されるようになった「働き方改革」について、
 一歩立ち止まり、現状の日本の働き方をもとに本来あるべき「働き方改革」について問題提起している。
 働いている人は読んでほしい。



最後に

こうやって振り返ってみると、
自分がどういうことに興味があるのか丸わかりで面白いですね。

皆さんはどんな本を読んでいるのでしょうか。

ただ、せっかく読んだのに
1か月後には内容を忘れてしまうこともしばしばありますよね。

以前読んだ本「読んだら忘れない読書術」に、
アウトプットすると良いとありました。

特にSNS等に投稿するのが良く、
理由はちゃんとまとめなきゃ感が出るので、
理解が進み定着しやすくなるようですよ。

読書は典型的なインプット型の学習です。
是非アウトプットして定着させましょう!

以上

【Django】DjangoでBootstrapを使えるようにする3ステップ

f:id:qstairs:20160601221351j:plain

はじめに

Webアプリで大事な要素の一つは見た目、見栄えではないでしょうか。
ただ、私のようにデザインがよく分からないという方も多いはず。
そんなエンジニアを救ってくれるのがBootstrapというわけです。
#Webアプリ開発の達人である友人に教えてもらい、つい最近知りました。

BootstrapはCSSの「フレームワーク」で、
デザインが得意なとてもありがたい方々が用意してくれています。

今回私は、HonokaというBootstrapを使いました。
honokak.osaka

ということで、これをDjangoで使えるようにします。

やったこと

前回の記事の環境をもとに書きます。
qstairs.hatenablog.com

作業としては以下の3ステップで使えるようになりました。

  1. Bootstrapのダウンロード
  2. 必要なものをコピー
  3. ソースを修正

Bootstrapのダウンロード

まず、以下からzipファイルをダウンロードし、解凍します。
Release Honoka v3.3.7-a · windyakin/Honoka · GitHub

解凍後のフォルダ構成は以下になります。

honoka
├── README.md
├── bootstrap.html
├── css
├── fonts
└── js

必要なものをコピー

まず、staticフォルダを作成し、
そこにcss,fonts,jsフォルダをコピーします。

コピー後のフォルダ構成

├── bin
├── blog
│   ├── __pycache__
│   ├── migrations
│   └── templates
├── include
├── lib
│   └── python3.6
├── myapp
│   └── __pycache__
└── static    #作成
    ├── css       #コピー
    ├── fonts    #コピー
    └── js          #コピー

ソースを修正

準備ができたところで、ソースを修正します。
Bootstrapを使用するために必要な修正は2ファイルです。

1. myapp/settings.py

    :
    :
STATIC_URL = '/static/'
# 追加 start
STATICFILES_DIRS = [
    os.path.join(BASE_DIR, 'static'),
]
# 追加 end

2. blog/templates/blog/post_list.html
※post_list.htmlは、ダウンロードしたzipファイル内にあった「bootstrap.html」で上書きしています。

     :
{% load staticfiles %}
  <link rel="stylesheet" type="text/css" href="{% static "css/bootstrap.css" %}">

(略)

<script src="{% static "js/bootstrap.min.js" %}"></script>
    :


こんな感じでちゃんと表示できました。
f:id:qstairs:20170504152226p:plain

最後に

最初いろんなサイトを見ましたが、
情報が錯綜していて一体どれが正しいのかわかりませんでした。
試行錯誤により、今回紹介した方法でBootstrapを使用できることがわかりました。
フタを開けてみれば大した修正なく使えるようで、
今後どんどん使っていこうと思います。

以上

【Django】Django始めました

f:id:qstairs:20160601221351j:plain

はじめに

前にRuby on RailsによるWebアプリケーションの開発について勉強しました。

qstairs.hatenablog.com


今回は、Django(これでジャンゴと呼ぶらしい。)を使ったWebアプリケーションの開発を勉強します。
Djangopythonをベースにしたフレームワークです。
pythonということは、
ChainerなんかのDeep Learningを簡単に使えてしまうということです!

環境

今回は以下の環境となっています。
OS:Mac OSX 10.11.6

Django 1.11
python 3.6.1

Webアプリの作成

参考にしたサイトは以下になります。
PythonのWebアプリケーション(Django)を初心者にもわかりやすく解説(1)【環境構築編】 - Qiita

基本的にサイトの通りに進めればWebアプリを作ることができました。

ただ、注意点として、
サイトの途中でpythonの実行が「python3」ではなく
python」となっている場所があります。
Django「python3」です。
#Macはデフォルトでpython2.x系がインストールされているため、
#pythonとするとpython2.x系が実行されてしまいます。

ちなみに、所要時間は環境構築合わせて2-3時間ほどでした。




ちょっと脱線

MVC vs MTV 問題

これらは開発のデザインパターン(各機能を分けて整理しよう的な考え)を表す言葉です。
Ruby on Rails等はMVC(Model,View,Controller)を採用(推進?)し、
DjangoはMTV(Model,Templatem,View)を採用しています。

MVCとMTVはどちらも言ってることはおおよそ同じなのですが、
ネット上で争っているらしい...

プログラミングのデザインパターンでさえこれだけ論争が起きているのだから
世の中から争いが消えることは当分なさそうですね(^_^;

最後に

今回はDjangoを用いたWebアプリケーションの基本的な開発について勉強しました。
個人的な感覚では、Ruby on Railsのほうがすっきりしている気がしました。
ただ、Djangopythonをベースにしているということで、
私がこれから開発していきたいサービスを考えると
機械学習が容易に使えるpythonをベースにしているのはとても魅力的です。

今後はDjangoに絞って勉強していきます!!


以上

【ITエンジニアの実情】フリーランスを1か月経験して感じた会社による働き方の違い

f:id:qstairs:20170209000813j:plain

はじめに

3/31で4年間勤めた会社を退職し、
4月からITエンジニアのフリーランスとして働いて1か月がたちました。

私がエージェントに 仕事を探してもらう際に提示した条件は
とにかく残業が少ない職場で!
というものでした。

この条件で仕事を探してもらい、
今の現場の面談を受けた際には
稼働は安定している=残業はほぼない
と聞いていました。
とはいえ、
実際は20時間ぐらいは残業することになるだろうと考えていました。

では、4月も終わったので結果を発表します。
残業時間はなんと、
0時間
でした。
驚くことに毎日18時前には退社するという素晴らしい日々を送っています。

また、仕事内容はと言いますと、
1つの作業を余裕のある納期で進めるという
前の会社ではありえない状況に困惑しています。
#もちろん、入って間もないため納期に余裕を持たせてもらっていますが。

ちなみに、前の会社では3~6の案件を並列に進めていき、
中には短納期なものもありました。

なんで同じIT業界で働き方に差が出てしまうのでしょうか。

私が思うに、以下3点が理由として挙げられるのではないでしょうか。

  1. 扱う技術の違い
  2. 顧客を固定できるか
  3. 顧客が業界トップシェアか

では、それぞれに関して以下に記載していきます。



扱う技術の違い

働き方に差が出る理由の1つ目としては、
扱う技術が全く異なることが原因ではないかと思います。
つまり、世間に定着した技術か未知の技術かということです。

前の会社では、最先端の技術を使用した案件がほとんどでした。
最先端の技術は顧客も「相場」が分からないため、
どうしても低く見積もられます。
また、先陣切って最先端の技術を使いたいと言ってくれる顧客は少なく、
こちらとしては何とかして受注したい、実績を残したいという思いがあるため、
比較的少額で短納期でも受けざる負えない場合もあります。

一方、定着した技術は、
基本的にある程度の市場規模が確立されているため、
(だからと言って儲かるというわけではない)
顧客もその技術の「相場」を(調べれば) 理解でき、
双方納得した上で受注しやすくなります。

つまり、扱う技術によって、
顧客と受託側のパワーバランスが変わることで働き方に差が出ているのではないでしょうか。

顧客を固定できるか

働き方に差が出る理由の2つ目としては、
顧客を固定できるかという点です。

顧客が固定されるとどうなるか、
顧客にとっても受託側にとっても互いを切り離せない関係になります。
つまり、信頼関係が生まれます。

するとどうなるか、
顧客もある程度のことであれば受託側の意見を聞き入れるようになります。
よって、開発内容に関しても、納期に関しても受託側には余裕を持たせることができます。

ただ、顧客を固定すると様々な問題がありますが...

顧客が業界トップシェアか

働き方に差が出る理由の最後としては、
顧客が業界でトップシェアかという点です。

顧客が業界でトップシェアだと何が良いのかというと、
簡単に言えば、お金を持っている(可能性が高い)ということです。

顧客がお金を持っていると、買い叩かれる可能性が減ります。



最後に

いかがでしょうか。
正社員として4年間、フリーランスとして1か月働いた中で感じた、
会社(職場)による働き方の違いの原因についてまとめました。

ただ、個人的な肌間隔によるもので、
定量的な数値を使用しているわけではありません。
なので、( ´_ゝ`)フーンという感じで受け取っていただければと思います。



「一人でも多くのITエンジニアに幸せになってほしい。」

そう願う限りです。

広告