「労働者側の裁量で深夜労働もできる勤務体系」をまじめに考えるとクッソ大変な話 - terurouメモ
これを読んだ。 tech.grooves.com 就業規則おじさん枠として、「労働者側の裁量で深夜労働もできる勤務体系」について言及しようと思う。労働法のエキスパートではないので、実際に検討をする場合は社労士と相談が必須。 お前誰よ 過去にこんなことをした。 terurou.hateblo.jp 本業ではないので労働法のエキスパートではないが、 自分で就業規則をゼロから書き起こした零細企業実務者 就業規則は執筆中～施行前まで社労士チェックが何度も行われている みなさんが期待する裁量労働制・なんでもありフレックスタイムを本気で検討したが、制度設計・運用がともに無理だと思ったので断念した という前置きで。 蛇足だが、就業規則をGitHubをした影響で本業の社労士さんからコメントを頂くことがチョイチョイあるが、「ちょっと気になるところがあるけど、大体こんなところだよね」という評価である。 元記事
エンジニアは業務時間外に勉強すべきかの話 - terurouメモ
他社社長が盛り上がってるみたいなんですが、そこの言説だけが広がっていってもアレだなぁと思ったので、単に自分がやってきた経験値とかを書いてみた。銀の弾丸欲しい。 お前誰よ 零細ITシステム会社経営 従業員5人、エンジニア数だと6人（私自身が含まれる） 会社は設立して4年弱 自社サービスを作っているが、今のところの収益構造は受託・SESが100% 10年ぐらい名古屋でコミュニティ活動に関わってきている（ただし、ここ2年ぐらいは忙しすぎて、ほぼ勉強会に行けてない） 色々やってきて至った基本的な考え方 会社という組織を前提とするのであれば「雇用契約」による利害関係で考えるのがシンプル。 会社は利益を上げたい 利益を上げる手段としては、良いエンジニアが必要（それだけではないが、この話題の本筋ではないので割愛） 良いエンジニアを育むには学習が必要 目的は利益であって、エンジニアの勉強は手段。エンジニア
安定寄りの零細IT会社を作って1年ちょいで得た知見 - terurouメモ
デンキヤギ株式会社という名のITの会社を作ってから1年強になった。 自社プロダクトを事業の中心に据えたいとは考えているが、まずは安定経営のため受託開発を優先してきたことにより得た知見をまとめておく。ちらほらと「会社を作ってどうよ」みたいな事は聞かれた際に、まともに答えてきていなかったという自覚があるので、その回答でもある。 設立以前から現在までのざっくりの状況 中小SIerでサラリーマンエンジニア歴10年（うち5年ぐらいはR&D部門所属） 名古屋ローカルではあるが、コミュニティ活動はガッツリやってきた方 まずは1人だけの株式会社を設立 設立から1年ちょいの間に社員を2人採用 現時点では受託開発中心で、安定に寄せた経営方針 業績はボチボチ、倒産の危機とかはない程度には良い とりあえず受託で食っていくために必要なもの カネ コネ 相場・市況感 ちゃんと仕事を回してちゃんと納品する能力 さえあれ
Haxe/JavaScriptでSource Mapを出力するための設定 - terurouメモ
ざっくりこんな感じです。 -cp src -main Main -js bin/main.js -debug -D source-map-content"-debug" オプションを付けると、Source Mapが生成されるのは皆さんご存知だとは思いますが、これだけだと、HTTPサーバに配置した場合にSource Mapが読み込めません。これは、Haxeの生成するSource Mapでは、sourceRoot が file:// になってしまっているせいです。 で、ちょっと楽ができないものか調べていたら、3.1.0から(?)、"-D source-map-content"オプションが増えていたようです。これを有効にすると、sourcesContentにソースコードが埋め込まれるようになる＝そのままHTTPサーバに配置してもSource Mapが使えるようになります。 changesにも書か
GitHubに会社の就業規則を公開した - terurouメモ
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです！！！！」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった（後述あり） いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの？ 従業員が10人未満
HaxeのJavaScriptターゲット用のビルトイン - terurouメモ
Haxe 3.0から __js__() 以外にもいくつか追加されてたらしい。知らんかった。 The Haxe Magic - Haxe untyped __js__(js : String) : Dynamic インラインJavaScript。 var console = untyped __js__("console"); untyped __js__("console.trace()"); untyped __instanceof__(obj : Dynamic, type : Dynamic) : Bool JavaScriptの"instanceof"。@ktz_aliasさんが、標準APIのStd.is()を使えば良いのではって言ってたけど、本当にそうだと思う。 if (untyped __instanceof([], Array)) { // if ([] instanceof
Haxeで仕方なくnullと付き合う - terurouメモ
Haxeは現時点で選択しうるaltJSの中では型システムが一番出来が良く、代数的データ型（Haxeではenum）が扱える点が素晴らしい。しかし、元々はFlashを前提とし、今はマルチターゲット（JavaScript、PHP、C++、C#等）にコンパイルする言語として設計されているため、どうしてもnulを扱わなければならない。 これはHaxeに限った話ではなく、F#やScalaなどでも同様の問題があるのだが、これらの言語と比較すると、Haxeはすこしnullが全面に出てしまっている（むしろnullを許容する言語設計にすることで、学習時の敷居を下げているのではないかとも思えるが…）ので、nullを根絶したい勢にすると、ちょっとぐぬぬとなる面がある。 少し前置きが長くなったが、Haxeで仕方なくnullを付き合うための方法の1つを書いてみる。 そもそも、nullを使わないコードとは？ Optio
Re: HaxeとTypeScriptを両方使ってみた感想 - terurouメモ
HaxeとTypeScriptを両方使ってみた感想 - ジンジャー研究室 に対してのコメント。コメント欄ではレスを書くには余白が狭すぎです。 if式について HaxeのifはBool型しか受け付けないため、存在判定はnullとの比較が必須になる。JavaScriptからHaxeに移行するとifの度にコードが膨れ上がってしまう。 同じく、&&と||もBool型でないと使えない。これは正直とても不便だ。 生JavaScriptでもたまに問題になる暗黙の型変換でfalseと判定されてしまうケースを考えると、Boolしか受け付けないことには利点があります。私はむしろHaxeの考え方の方が正しいと思っています。 // JavaScript var i = 0; if (i) { // こっちは通らない } else { // こっちが通ってしまう！ } enumとパターンマッチ nullチェックの話
Haxe使いから見たTypeScript雑感 - terurouメモ
TypeScript良いですね。世間の流れは完全に動的型付け言語から静的型付け言語＋型推論に移ってきていますが、JavaScriptの上にうまくそれを導入してきた感じです。ヘルスバーグはやっぱすごいよね、と。 今後実装される予定のジェネリクスが載ってきたら、better JavaScriptとしては最強言語の一角になりそうな雰囲気ですね。 CoffeeScriptとTypeScriptについて 言語仕様としては正直別物レベルの存在なのだけど、ツールとしての性質（コンパイラがJSとして動作するなど）が大きく似ているため、Web上ではよく対比されてるようです。 TypeScriptが世に出てきてしまった以上、CoffeeScriptは「型付けのできないTypeScriptの出来損ない」みたいな存在になってしまったかなぁと。TypeScriptの出現以前から、CoffeeScriptには採用する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
