MESSAGE 私たちは、 「チャレンジ」し続け、世の中にないサービスを提供します。 「プロフェッショナル」として、自信を持ってサービスを提供します。 「エンジョイ」する事によって、お客様をはじめ、関わる人達みんなが幸せになるサービスを提供します。
最近はようやく本格的に vim を使ってコーディングするようになりましたが、まだまだ慣れない & 微妙な不満があったりします。 移動系がキーボードで全てできるのは、確かにかなり楽なように思えます。 話が変わりますが新しく違う言語を勉強しようと思う時、何を一番初めに調べますか? 構文はもちろん、インストール方法とか色々ありますよね。ボクが一番重要視してるのはデバッグ方法です。 どうやってデバッグするか。まずその方法などを調べます。 LL系言語の方は 変数を printしたりする方が多いらしいのですがボクはあまり好きではないので PHPの場合は Xdebugを利用してステップ実行させたりしてます。 print させるのが嫌いな理由は一つです。 「コードを書かなくちゃいけない」 これに尽きます。なんでデバッグするのにコード書くんだよ!って思ってます。 前置きが長くなりましたが、素晴らしいプラグイ
Middleman にはブログ機能拡張の middleman-blog があります。 このブログも使っています。 ブログの記事には日付を設定できますが、実は middleman-blog は未来の記事を生成対象から外します。 基本的に便利な挙動なのですが、時々困ることがあります。 未来の日付の記事を途中まで書いておくことがありますが、生成されないので確認できないのです。 もちろん、記事の日付を過去にすることで生成されるのですが、面倒ですし、変更し忘れてそのまま公開しそうです。 調べたところ、記事自体は変更せずに、未来の記事を生成することができました。 Middleman で未来の記事を生成する方法 config.rb に以下の記述を追加します。 activate :blog do |blog| ... blog.publish_future_dated = true ... end なお、
うづらルビーカイギ(http://udzura.rubykaigi.me/)に参加してきました。 最初話題がでたとき、あきらかにネタ的な感じで、私もネタとして参加表明したんですけど、本当に開催されてよかったですね。 ーー アッ、いままでうづらルビーカイギだと思ってたのに、実は違う会だった??!! #udrk ーー まとめ すごくたのしかったので、第二回を期待したいですね。 あと、すがさん早くジョーカノ(を僕とにょんたんに、彼女さんの親御さんにすがさんを)紹介してください。 ーー @sugamasao とキャバレー雰囲気のある感じの(略 ーー (かってにしゃしゃったらキモいのであまりやりませんでしたけど、次回やるなら率先してお手伝いします) 感じた事 しょうじき、PHPerかつCGIおじさんはルッビーの事全然わからないので、当日PadrinoをいれてScaffoldingしてみたりしたくらい
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
12年間に渡りスティーブ・ジョブズと仕事をしたクリエイティブ・ディレクター、ケン・シーガル氏の講演を聞かせて頂いたのですが、iMacのネーミングについて面白い逸話がありました! 今回の講演は、ケン・シーガル氏が出版した「Think Simple」を記念したもので、六本木のアカデミーヒルズで開催されました。シンブルさの重要さについて講演されました。 その中で、iMacのネーミングをした際の逸話が興味深かったです。 (全文は「Think Simple」刊行記念セミナー“クリエイティビティとイノベーションを生み出す熱狂的哲学”レポートからどうぞ!) ////// iMacを初めてみた時、驚いた。本当に社運をこれにかけていいのか、と。1週間くらいスティーブ・ジョブズとミーティングした。その時は「C1」というコードネームだった。iMacという名前を最初から気に入った訳ではなかった。彼は妥協しない人だ
2014-09-11 社内クローズドなリポジトリをGitHubに公開するのは色々つらいけど、おかげで色々解き放たれた件 Github Maven Scala どうもこんにちは 先月AeromockをOSSとして公開しましたが、もともとこれは社内のGithub Enterpriseにあったリポジトリで、OSSとして公開するためには色々と紆余曲折がありました。というわけでクローズドなリポジトリをGitHubに公開するまでにやったことをまとめてみます。 概要 リポジトリはAmeba内のGitHub Enterprise Scalaで書いてて、ビルドはsbt サブプロジェクトだけ一部Gradleプロジェクト 成果物(Jar)は社内クローズドなnexusにディプロイ ドキュメントは全てAmebaのCofluenceに書いてた(社内限定情報含む) Mavenリポジトリ OSS化前は、社内のクローズドな
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり) いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの? 従業員が10人未満
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く