日本のエンジニアの地位をあげるために - UNIX的なアレ
日本のITはなぜ弱いのか？ 日米でこんなに違うプログラマーの扱い - まぐまぐニュース！ 確かにその通りで、やはりエンジニアは言われたものを作る職業という認識をされているケースが多いです。最近のエンジニアが主体となったベンチャー企業などでは変わってきているとはいえ、業界の割合でいえばごく一部といえると思います。 上記の記事にもある通り、サラリーマン経営者による個人の責任を極限まで減らした意思決定を行いそれによってプロジェクトが遂行されることが正義とされてしまうと、どうしてもエンジニアとしてのクリエイティビティを出すチャンスは減らされてしまいます。これに対してどう向き合えばいいのかを考えてみました。 なお、英語学んで海外に行けばいいじゃないかという個人にフォーカスした視点はいれません。 IT人材の人数は2019年がピーク IT人材の育成（METI/経済産業省） こちらのデータを見る限り、20
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
nanapiのこれから、変わることと変わらないこと - UNIX的なアレ
すでにメディアで取り上げられているのでご存じの方もいると思いますが、本日このような発表をいたしました。 http://nanapi.co.jp/news/133 変わること 「変わることと」表現していますが、我々がもともとやろうとしている「What」の部分が変わるわけではありません。あくまで「What」を叶えるための「How」の部分が変わるだけです。 株式会社nanapiは「できることをふやす」というミッションを掲げています。そのミッションをいかにして達成するのかを考えた結果、もっとも最適な選択肢として今回の結果になりました。 http://www.syndot.jp/ 変わらないこと 連結子会社となっていますが、株式会社nanapiとしては基本的にやることは変わりません。我々が運営するnanapi.jpやアンサーに関しても今までどおり運用し続けますし、これからもよりよいサービスになるよう
文章の書き方を変えるだけで社内の情報共有は加速する - UNIX的なアレ
社内の情報共有で困っている会社は多いみたいですね。でも実は、nanapiという会社ではそこまで困っていなかったりします。元々文章を扱う会社というのもありますし、ドキュメント化して共有しようという風土が染み付いているからだと思います。 そういったこともあり最近登壇するときなど、社内の情報発信などについて話す機会が増えました。弊社では社内における情報共有のツールとして、Qiita:Teamを使用しています。 生産性を向上させる情報共有ツール - キータチーム（Qiita Team） 全員がMarkdownで文章を書く 実際にnanapiではQiita:Teamを導入してから、現在ではエンジニアだけでなくアルバイトも含めた全社員がここに様々なドキュメントを投稿しています。 Qiita:TeamはMarkdownで書けるようになっています。つまり、社内のメンバーは全員がMarkdownで文章を書く
Eigooo!はエンジニアが英語を学ぶのに最適な方法かもしれない - UNIX的なアレ
英語ってやらないといけないじゃないですか。これはたぶん誰も否定はしないと思います。ただ弊社経営陣の英語力が非常にアレでですね、なんとかせんとまずいということで最近頑張ってます。 なぜメディアはグローバルに挑戦しないといけないのか : けんすう日記 まぁそんなわけでいろんな英語学習しているのですが、ここ最近、Eigooo!というアプリで英語学習をしています。 Eigooo! Anytime, Anywhere English これがなかなかよくできているアプリで、ネイティブの人と英会話ではなく英語でのチャットをするんですね。まだiOS版しかリリースされていないのですが、非常によいアプリです。 エンジニアはまずは読み書きが最優先 当然、会話は出きるべきですし、読み書きとはまた異なるスキルではあります。ただ、日本国内でエンジニアが英語が必要となるケースは読み書きでしょう。 実際に英語のネイティブ
Unixに関するいろいろな略称とその意味 - UNIX的なアレ
いろいろな略称が多い！ コマンドやディレクトリ名など、UnixなOSはとにかくいろいろな略称が多いです。特にさわりはじめの人はこの略称がいみわからずに心が折れてしまうことは多いと思います。実際にSchooでUnixの授業をやったときもこの略称を説明しました。 というわけでまとめてみました。なぜ略称が多いのかが気になる人はこちらを読んでみてください。 UNIXという考え方―その設計思想と哲学 作者:Mike Gancarzオーム社Amazon ※ちなみに、Linuxにもほぼ通用すると思いますがMacをベースに書いているのでUnixという表記にしています。 ディレクトリ名 名称 本来の意味 備考 usr User Services and Routines これは若干怪しめです。Userという説も var Variable ログやメールの情報など、変わりうる情報を扱うもの tmp Tempor
初めてシェルスクリプトを書くときに知っておきたいこと - Unix的なアレ
他の言語をを書き慣れてから、シェルスクリプトを書こうとするとしょうもない部分でハマったりすることがあります。「簡単な処理だからシェルスクリプトで書くか」と思っても無駄に時間がかかってしまっては仕方ないですよね。 今回は初めてシェルスクリプトを書くときに、ハマりそうな点について説明をしたいと思います。 実行権限をつける 単純にファイルを生成しても下記の用に実行しようとしても実行はできません。 # touch test # ./test sh: ./test: Permission denied # touch foo # ./foo sh: ./foo: Permission denied これはファイルに実行権限がついていないため、起きる現象です。 chmodコマンドを使って実行権限をつけてやりましょう。 # chmod +x test # ./test # chmod +x foo #
いかにしてベンチャーの社内ネットワークを構築するか - UNIX的なアレ
情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
