サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
Talknoteはフィードによるリアルタイムの情報共有をはじめ、データの蓄積や組織運営の改善など、働く人が最大限にチカラを発揮できる環境づくりをサポート。最前線で働くプレイヤー1人ひとりから組織を強くしていくことで、あなたのビジネスをさらに加速させていきます。
AWS アカウントを複数人で使ってシステムを作っていく時に、 セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所の Blog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考: AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。 AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザ AWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザ AWS アカウント周り AWS アカウント (ルートユーザ) で作業できないように
ここまで来るのに時間がかかりましたが、今ではiPadもiPhoneに劣らないくらいアプリが充実しています。選択肢が多すぎて、価値のあるアプリを見つけ出すのが難しいくらいです。米Lifehackerイチオシのアプリを集めた「Lifehacker Pack for iPad 2014」を参考に、あなたの時間を節約してください。 生産性向上ツール Mailbox or Evomail iPhoneではメールアプリが山ほどありますが、iPadでは選択肢は限られます。どのアプリがベストかはあなたの使い方次第です。メールの新しい使い方を提案した『Mailbox』は、iPad版もかなり良い出来です。従来型のメールアプリがいいなら、『Evomail』がシンプルでオススメ。完璧とは言えませんが、無料ですし、試す価値があるアプリです。 Drafts 『Drafts』は、シンプルさと、パワーユーザー向けのオプシ
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集(リンクとコンテキスト追加)を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集(転載元:http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ) なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん(旧メールアドレス masarl@nifty.com)の記事を転載します
マルバツゲームとは 二人でマルとバツを交互に書いて行って、先に三つ並べた方が勝ちっていう例のやつです。 これの作り方を通して、「Swift分かんない」「iPhoneアプリ作ったことない」という人がiPhoneゲーム開発の第一歩を踏み出すことを目的としたチュートリアルです。 他のプログラミング言語の経験も全くない方でも一応出来ると思いますが、専門用語がちょっと難しいかもしれません ^^; その辺は、まずは目をつぶって頂いて、とりあえず書いてある通りにやってみて下さい。 iPhoneアプリ開発環境であるXcodeの準備とSwiftのとっかかりとしては、こちらのチュートリアルをご覧下さい。 続編も公開中 新しいゲームプロジェクトの開始 プロジェクトの開始方法は2通りあるので、どちらかで Welcome to Xcode画面でCreate a new Xcode projectを選択する もしくは
個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい! prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 (以下正確ではないですが簡単に) Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり) いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの? 従業員が10人未満
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く