何か「ポジティブに取り組んでいる」ことがあるのなら、ひっそりこっそりなんてモッタイナイ。うまく周囲にアピールしましょう。そうすることで会社でも地域社会でも、おのずと良いポジションが手に入ります。
スポーツでも趣味でもなんでも良いです。その時点で実績が伴っていなくても大丈夫。大切なのは「ポジティブに取り組んでいる」という事実を、周囲の人に伝えることです。
周囲の人たちは、それぞれ個人的に抱いている「最高にポジティブな人」のイメージを勝手に重ね合わせてくれて、組織内の空気があなたの背中を押してくれるようになります。
「アピールしなくても見てくれている人はいるはずだ」という主張は正しいかもしれませんが、それでもアピールしているほうが効果は顕著。
ただ、無理にポジティブになろうとするのは無しですよ。ココロとカラダを悪くしますし、周囲に「無理している」ことすらバレてしまいます。
最近（仕事で）久しぶりにC++を触っている。Windowsだけど、Linuxでも動作するようにしなくちゃならんので、STLを使っているが、独特の雰囲気があって、戸惑うことも多く、ちょいちょい調べて対応してるが、ここに覚え書きとして書いておく。後に増やすかもしれない。
#include <filesystem>
std::tr2::sys::path pathname("/foo/bar.baz");
pathname.basename();//ファイル名から拡張子を抜いたもの
pathname.extension();//拡張子。最後のドット以降（ドット含む）
pathname.branchPath();//#include <algorithm>
#include <string>
std::string str = "Hello World";
std::transform(str.begin(), str.end(),str.begin(), ::toupper);ofstreamで開いたファイルの、現時点での書き込み位置を取得するには、tellp() メソッドを使用する。
プロトタイプ
#include <fstream>
streamoff ofstream::tellp();サンプルコード
//追加書き込みで開く。なければ作成される
std::ofstream ofs;
ofs.open(pathname, std::ios::app);
//書き込み位置を取得する
std::streamoff writePosition = ofs.tellp();
if(writePosition < 0) {
//失敗
}
if (writePosition == 0) {
//ファイルの先頭
} else {
//既存内容の最後に追加
}ログ的な出力ファイルを追加書き込みモードで開いたとき、実際にはそのファイルの先頭から書き込もうとしているのかどうかを知りたかった。
ファイルを開く前に、ファイルサイズやファイルの存在をチェックする方法を取る人がいるかもしれないが、あまり良いやり方ではない。事前チェックをするのは良いが、その後実際に開くまでの、わずかな間にでもファイルの状態が変わりうるためだ。
まず対象のファイルを開いて、状況を変化させ得る他のプロセスをブロックし、それからチェックするのが望ましいし、よりシンプル。
Googleさんから８月下旬にメールが届いた。内容はこんな（↓）感じ。
あなたのWebサイトでテキストボックスが使われてるが、ブラウザとサーバー間の通信が暗号化されないHTTPなので、10月以降 Google Chromeではユーザーに警告が表示されるようになりますよ。
HTTPのウェブサイトにユーザーが入力したテキストは、サーバーへ送られる間に外部から傍受できてしまうから、Google Chromeは「危険である」との警告文を表示するということ。
確かに自分の（このブログではない）WEBサイトでは、一部のページでテキストボックスを使っているが、ページ内で利用するのみでサーバーへは送信しない。でも、Google Chromeは、実際に送信しているかどうかまでは確認せず、ページ内にテキスト入力する所があれば問答無用ということらしい。
チェックボックスやラジオボタン、リストからの選択などは対象外とのことでした。ユーザー自身の操作で自由に情報を書き込めるテキストボックスには、個人情報が含まれる可能性があるので、サイト管理者以外の人に盗み見られてしまう可能性について警告するということですね。
そこで、Nifty Lacoocanに「HTTPSプロトコルに対応する気はありますか？」と問い合わせたら「無い」とのことでした。年間１万円程度支払っているのに、ユーザーに危険だと表示され、対処法がないのは非常に困る。
仕方がないのでHTTPSが使えるサイトへ移行することにした。
BloggerもHTTPSが使えるので検討したが、元のサイトの一部のURLはかなりアクセスがあるため、301でリダイレクトするひつようがある。そのため、デザインをほぼ崩さずに移行するため、ブログは適当ではないと判断。
そこで既に持っていたGitHubのユーザーページへ移行することにしました。無料ですしね。
元ページは、PHPで俺様フレームワーク（笑）を使っているが、GitHubのユーザーページは基本的には静的ページであり、PHPが使えない。
なので、俺様フレームワークを少し改造してローカルで静的HTMLを生成しユーザーページへPush。
やる気が起こらず１ヶ月近く放置してたが、やり始めたら作業量的には１人日だったかな。
仕事でも趣味でもスポーツでも、なにか一つのことを上手くやれるようになるには、いろんなものを入力して成果を出力するという、一連のプロセスを繰り返す必要がありますねという話。
座学的な事前学習も必要だけど、それはスタートラインのレベルを引き上げるための入力と言えるでしょう。
モノ作りであれば、入力は世間のニーズや、新技術、新しいプラットフォームなどになるでしょう。出力は成果物を公開するということになるでしょうか。
「上達＝成果のクオリティが上がる」ということですが、途中段階の低いクオリティのものでも、正しく出力する（つまり完成させる）べきです。次のサイクルでは、それ以上の品質を出せるはずなので、納得いかなくても、まずは出力して、次のサイクルに取り掛かればよいのです。出力する前に、クオリティがどうとか気にして断念すると、次のサイクルに進めないから、いつまで経っても上達しない。
自分は、主に趣味の分野では、目指しているクオリティが出せないと諦めて、ゼロから作り直してみようとする癖がある。想定したクオリティが出せないのは、なにか未熟であって、入力が足りていないのかもしれない。つまり「必要な訓練ができていない」ということだろう。
恥ずかしくても笑われようとも、公然とその時の精一杯の出力をすればよいのだ。
そして「上達するには入出力を繰り返す」
自戒を込めて。
概要： ブラウザで使えるマークダウンエディタStackEditからBloggerに、日本語タイトルの記事を投稿すると、変なURLで公開されてしまいますが、これを回避する方法を書いています。
関連記事
StackEditでBloggerに投稿すると、StackEditでのタイトルがURLのファイル名部分に使われます。でも日本語が使われてると勝手に変更されて意味がわからなくなってしまいます（半角英数字は残ります）。Bloggerでは、URLにパーマリンクを設定できるらしいのですが、StackEditからは設定できません。
一方、StackEditからBloggerへ発行する場合、本文の先頭で、以下のようなセクションを設けることで、ページのタイトル、ラベル、公開日時、公開属性を指定できます（これはダイアログで説明されています）。
（例）StackEdit本文先頭でBloggerへの発行時に使用されるページ属性を指定
---
title: StackEditからBloggerにタイトルとURLを別に指定して投稿するには？
date : 2017-09-07 20:30:00
tags : [StackEdit,ブログ,Webアプリ,ツール]
published : true
---この機能を使って、StackEditの右上のタイトル欄に、URLとして使用したい文字列を設定し、タイトルは本文で指定すれば良いのではないか？と試してみましたがダメでした。どうやら本文でタイトルを指定するとそれがURLに使用されてしまうようです。
しかし、一度発行した文書はあとから更新できるため、あとでタイトルを書き換えて更新すれば行けるんじゃ？と、やってみたらOKでした。以下に手順をまとめます。
以上です。ちょっと邪魔くさいですけどできました。
StackEdit はブラウザで動作するマークダウンに特化したエディターです。まだ少し使ってみているぐらいですが、動作も軽いし、各種クラウドサービスと連携できて便利です。結構古くからあるみたいですがワタシは全然知りませんでした。とりあえずBloggerに投稿できました（簡単でした）ので使ってみた機能を御紹介。
関連記事
目次
編集しているマークダウン文書を各種クラウドサービスに保存できます。
実際にはファイル単位で同期（Synchronize）しているので、あとから開くのも簡単ですし、別のPCで作業しても問題ないはず。
同期できるサービスは DropBox、Google Drive、そして、Apache CouchDB（これは最近追加されたようです）。これらのサービス内のファイルへ保存したり、既に存在するファイルを開いたりして、同期できるみたいです。
同期とは別に、HTMLに変換して発行（Publish）できます。逆にHTMLからのインポートも可能なようです。
発行先は同期先より多くて、DropBox、Google Drive に加えて、グーグルの Blogger、Tumblr、WordPress などのブログサービスへの投稿や、 GitHub や GitHub Gist の Gitリポジトリへ（多分）コミットできるのでしょう。他に SSH Server なんてのもありますね。SCPでファイルを取ってくる感じでしょうか。しかし、カギの扱い大丈夫なんでしょうかね、ちょっと心配。ブラウザにSSHクライアントが実装されてるのならOKなのかも知れません。
出力フォーマットは、マークダウン、HTML、そしてテンプレートというのが選べます。
同期（Synchronize）と発行（Publish）は左上の「＃」をクリックして開くメニューから選択できます。
新規作成（New Document）や、既存のファイルを開くには、右上の「フォルダ」アイコンをクリックすれば選択できます。ファイルの削除（Delete Document）や管理（Manage Documents）もコチラのメニューから行えるようですね。
DropBoxへの保存機能では右上のタイトルに入力したファイル名とは別にファイル名を入力しなければならないようで、ちょっと面倒くさいと感じました。
一方 Google Drive では、ファイル名はタイトルと同じものになるのでワンクリックで保存できます。保存先はルートフォルダがデフォルトですが、Optionalな機能として、既存のフォルダを選べるようにもなっています。しかし、新規フォルダを作成して、そこに保存するのは無理っぽかった。
「＃」メニューの「Import from URL」でうっかり適当なURLを入力してしまうと、一時的に応答がなくなり動作しなくなってしまいました。
キャッシュをクリアしてエディタを開き直しても、ブラウザを再起動しても復旧せず。その日は諦めましたが、翌日、別PCからGoogle Driveに同期したファイルを Goolgle Drive から直接開くと復旧しました。
1日経過したから復旧したのか、別ファイルを開いたので復旧したのかは分かりませんが、お気をつけ下さい。
キャリアの裾野は広いほうが良さそうだってお話です。
キャリアって上に積み上げるイメージがあるけど、横にも広げておいたほうが良いですね。後からいろいろ積み上げやすくなりますから。
じゃあ、どうやって横に広げるかというと、いろんなことに手を出して、やってみる以外にないと思うんですよね。
ソフトウェアの業界に限らず、必要とされるスキルは時とともに増えていきます。世界は常に変化しているのですからね。そんな中、同じことを続けているだけでは停滞しているどころか相対的にできることが少なくなっていっているということです。そうすると、次第に損な立場に追いやられます。これに気付けていない人がいます。
逆に軽いフットワークで「なんでもやってみよう」とする人は、自動的に得する状況を手にします。周囲が自動的に良い条件になってくれる。
この「フットワークを軽く」というのは、なんでもかんでも「やりますやります」ではありません。普段からいろんなことに興味を持って「少し前のめり」に関わっているという姿勢が大切。自然に基礎部分が出来ているので、すぐに取り掛かれます。そして「やってみれば結構なんでもできるもんだ」という感覚も強くなりますから、さらにフットワークが軽くなる。明らかに好循環ですね。これで一気に差が開くんです。
1年程度ではわかりにくいけど、この差は大きく、5年、10年の中長期で考えれば、かなりな差がついてしまいます。「世の中は指数関数的に進歩する」と言われていますが、スキルの獲得曲線や、できる人とできない人の差の開き方なども、指数関数的なんじゃないかなと思っています。
だから普段から、キャリアの裾野を広げるように、なんでも興味を持って関わりたいなと思っています。
はじめまして。最初の投稿ですから自己紹介など。1969年生まれのソフトウェアエンジニア。1999年設立のソフトウェア開発関連企業の会社員です。
会社設立から10年ほど、プレイングマネージャー的に社内・社外のあらゆることに関わっていましたが、いろいろあって現在は、技術的なお仕事一本でやっています。
このブログには、自分の仕事を中心に、ふと思いついたことや考え方を、素直に気楽に書いていこうと思っています。 他にもウェブサイトやブログを持っていますが、気楽な雰囲気のがなかったので（日記的なのはありますが）。 伝えたいことを深く掘り下げ、正確に書こうとすればするほど、頭の中でグルグル回って結局外に出せなかったり、一緒に毒も吐きそになったり、そういう邪魔くさいのは避けたいなと。
タイトルの「KZ-WORKS」の「KZ」はイニシャル的なもので、それ以上の意味はありません。
「WORKS」は、なんていうか、その、かっこいいっぽいから（笑）
画像処理関係とか、人工知能関連には興味があります。
開発言語は大抵なんでも触ります。中学生の時に8ビットのマイコンに触れる機会を得て、まずは最初はBASIC。それから速度重視でZ80のアセンブラを独学し、その後 C/C++、VB、Perl、AWK、Java、JavaScript、C#、PHPと、世の流れに追従してきました。最近はNode.jsがお気に入りです。ここ数年で個人的に最も多く使っているのも JavaScript だと思います。
20年近く同じ会社で技術職を続けていると、後輩さんたち若人が新たな能力を身に着けて、管理職にキャリアアップしたりして、それは密かにうれしいものです。しかし、そういう個人や組織の成長途上って、何処かで何かが噛み合っていないような事がよく出てきます。階段を登るとギシギシ軋む音が聞こえるような感じですかね。早く登ろうとすれば、その分音も大きく鳴ります。
そんな様々な顕在化していない問題は、かつて自分も経験していて、自覚はないけど困りながら悩みながら、どうにか解決してきたんですよね。最近そんな風に思うことが多くなってきて、彼らにこっそりアドバイスすることもたまにあります。そんな具体的な対処法や、抽象的な考え方なども書いていければと思っています。あくまでも個人的な考えとしてですけどね。
とか色々書いてると長くなるので、まあ、そんな感じで気楽に書いていきます。よろしくお願いします。