CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
様々な人々から、エンジニアに関する制度についてインタビューされる機会が増えてきた。その中で考えが整理されてきたパーツもあるので、せっかくなのでまとめておこうと思う。 ペバボのエンジニア職位制度のアップデートについてなどで書いている通り、ペパボはエンジニア専門職制度を制定し運用している。その前提として、専門職制度がどのような位置付けかというと、簡単に示すと以下の図の通りである。 この構造自体は特になんの変哲もない、わりと一般的な制度だといえるが、我々はこの中にひとひねり加えている。以下に説明する。 前提知識 ただし、その前に人事制度における前提的知識について述べておかないとならない。 社員格付け 昨今は「フラットな組織」「ネットワーク型組織」などというものも出てきているが、それはそれとして、一般に企業組織は、その構成員をなんらかの方法を用いて格付けしている。すぐに思い浮かぶのは、部長とか係長
2. 株式会社フィードテイラー @ 2014.9.5 社名株式会社フィードテイラー 所在地大阪市北区 事業iOS(iPhone/iPad)アプリ開発 iOSアプリ 企画コンサルティング 資本金1000万円 従業員7名 賞・認定 大阪産業創造館 あきない・えーど賞 (2006) 大阪府中小企業支援センター テイクオフ大阪21 (2006) 大阪商工会議所 大商EVEシステム第6期 (2008) 大阪トップランナー育成事業 第2回認定 (2013) 新聞・書籍・雑誌掲載等多数 直近 の 実績 Wifi経由カメラロール操作アプリ「AirLib」 (iPhone有料App「仕事効率化」カテゴリ1位) ! 天気予報アプリ「そら案内」 (iPhone無料App「天気」カテゴリ1位。iPad無料App「天気」カテゴリ1位) グループ 会社SYNCNEL株式会社
たとえば$cmdがcat hogeであった場合、上記コマンドの実行結果の出力は次のようになります(hogeというファイルには「This is hoge」という文字列が書かれているものとします)。 execve("/bin/cat", ["cat", "hoge"], [/* 24 vars */]) = 0 ... (中略) ... open("hoge", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0664, st_size=13, ...}) = 0 read(3, "This is hoge\n", 32768) = 13 write(1, "This is hoge\n", 13) = 13 read(3, "", 32768) =
APIを作るとき みなさん、毎日API使ってますか?私は、ワンライナーでAPIをコールすることにハマっています。さて、いつも使っているAPIを作る側になったとき、どのように設計していますでしょうか?また、作ったAPIをどのように使ってもらっていますか?そんな疑問に応えるサービスがApiaryです。 Apiaryとは? Apiaryは、REST APIをサクッと書けるサービスです。また、APIドキュメントも生成してくれます。モックサーバも提供してくれます。API利用サンプルコードも作ってくれます。うん、使わないって選択肢は無いですねw。 無料登録すると早速使えるようになります。チームでプライベートなAPI開発をしたければ有料プランを選択してください。 API開発の流れ API開発の流れは、まずはじめにMarkdown形式でドキュメントを書きます。既にサンプルがあるのでこれを使ってみましょう。
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
iOS7.1からEnterprise配布がHTTPSでないとインストールできなくなりました。 apacheを自己署名証明書で構成した場合は信頼できない証明書のため、HTTPSでもインストールできません。 iOSデバイスでは"...に接続できません"とそっけなく表示されますが、デバイスをMacに接続し、コンソールログを見るとエラーの理由が分かります。 Xcode ⇨ Window ⇨ デバイス選択 ⇨ 右ペイン左下の△アイコンクリック itms-services:プロトコルに従ってurl先のplistをダウンロードするときにサーバ証明書が信頼できないエラーが発生しています。safariで直接plistをダウンロードするのであれば、ここで警告が表示され、サーバを信頼すればダウンロードを継続できますが、インストーラの場合は"...に接続できません"を表示して継続できなくなります。 いろいろ試した
とても便利なJenkinsですが、 たまによくしっかり ハマるので、その辺のポイントと私なりの解決法を共有します。 XCodeのプロジェクトが他のstatic libraryプロジェクトを含んでいる場合 まず、普通にXCode GUIを使っていてもこの辺は最初ハマることもあるかと思います。 特に static library側の Headerファイルが見つからない! というビルドエラーは結構悩まされます。 しかしこれをXCode GUIで解決するまではFAQのようで、ググると色々出てきます。 例) http://www.cocoanetics.com/2012/01/helping-xcode-find-library-headers/ ポイントは static library 側 Header を public にする Public Headers Folder Path を工夫する (
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く