サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブラックフライデー
blog.nikuniku.me
adventar.org 筋肉アドベントカレンダー2017の18日目の記事を書かせてもらいます。 いきなり半年トレニーング続けた感想を言ってしまうと 「めっちゃ楽しい!」「重い物を持ち上げたい!」 です。(現在ベンチプレス 90kg 1rep、スクワット、デットリフトはまだ計測したことがありません) 3ヶ月くらい続けた頃に「体つきが変わった」「ガタイが良くなった」と言われるようになってモチベーション高くなりました。 今回筋肉アドベントカレンダーでは、筋トレを始めたきっかけやトレーニングの始め方などを半年続けた目線で書かせてもらいます。 筋トレ半年の初心者の話で恐縮ですが、誰かの筋トレを始めるきっかけになってくれると幸いです!(この投稿は18日の昼くらいになってると思います…すみませんすみません) これから筋トレを始めるようと思う方へ まったくトレーニングしたこと無い人はいきなりジムに行くの
つい先日CodeDeployを試してみました。【AWS】5分で分かるAWS CodeDeploy その時はGithubと連携してデプロイを試したのですが、今回はS3で試してみたいと思います。 前回の記事で用意したApplicationを使いまわします。 S3バケットの作成 肝心のS3バケットを作成します。バケットのリージョンに注意しましょう。 CodeDeployはヴァージニア、オレゴンにしか対応してないので、それ以外のリージョンに作ってしまうとデプロイがDownloadBundleでコケます。 aws deploy pushでリビジョンのアップロード リビジョンとはデプロイするソースコードを指します。 リビジョンのアップロードにawscliを使ってみます。 ちなみにawscliのversion。2015/04/22時点の最新。 aws-cli/1.7.23 Python/2.7.5 Da
AWS最古のサービスSQSを今回は触ってみます。 SQS(Simple Queue Service)とは Amazon Simple Queue Service(Amazon SQS)には、コンピュータ間で送受信されるメッセージを格納するための、信頼性の高いスケーラブルなホストされたキューが用意されています。Amazon SQS を使用することによって、さまざまなタスクを実行するアプリケーションの分散コンポーネント間で、データを簡単に移動させることができます。 キューイングサービスですね。どういう用途に使うかというと、例えば処理を切り離したい時に使う事が出来ます。 DBのデータ更新系の処理だとして、リクエストを受け付けて、その後DBの更新を行うとし、このDB更新に時間が掛かるとします。更新が完了するまでの間レスポンスが帰ってこない状態になってしまうと思います。これを受付と更新とで切り分ける
NoSQLデータベースであるDynamoDBに今更ながら入門してみようと思います。 こちらの記事を参考に手を動かしながら、感覚をつかもうと思います。 AWS再入門 Amazon DynamoDB 編 | Developers.IO また、DynamoDBにはハッシュキー、レンジキーといった概念があるので、それらを理解する為にこちらを参考にさせて頂きます。 コンセプトから学ぶAmazon DynamoDB【Amazon RDSとの比較篇】 | Developers.IO コンセプトから学ぶAmazon DynamoDB【ハッシュキーテーブル篇】 | Developers.IO コンセプトから学ぶAmazon DynamoDB【複合キーテーブル篇】 | Developers.IO Amazon DynamoDBはマネージドなNoSQLデータベースです。RDBMSとは違い、リレーションやトランザ
apacheの設定をちゃんとわかっていないので、configをいじってみたいと思います。 今回はMaxRequestsPerChildです。 この設定は個々の子サーバが稼働中に扱うリクエスト数の上限を決めるもので、子プロセスが捌くリクエスト数を指します。 MaxRequestsPerChild ディレクティブは、 個々の子サーバプロセスが扱うことのできるリクエストの制限数を 設定します。MaxRequestsPerChild 個のリクエストの後に、子プロセスは終了します。 MaxRequestsPerChild が 0 に設定されている場合は、プロセスは期限切れにより終了することはありません。 今回検証する環境はこんな感じです。 ・Apache/2.2.15 (Unix) ・CentOS release 6.5 (Final) configはこんな感じ。 <IfModule prefork
MySQLのインサートにバルクインサートという"まとめていっきにインサート"するバルクインサートというものがあります。 通常のインサートより、処理速度が早いということなのですが、実際にどれくらい違うのか試してみたいと思います。 以下、環境。 OS:Mac OS X 10.7.5 CPU:1.7GHz Intel Core i5 メモリ:4GB MySQL:5.1 結果を言うとバルクインサートはめちゃ早いです。 郵便局のデータ約12万件を2秒程度でインサートできます。通常だと約11秒ほど。 郵便局のデータはこちらのブログの記事にあるものを使用させて頂きました。ありがとうございます。 MySQLにサンプルデータをinしてみる::郵便番号 | e2esound.com業務日誌 用意するテーブルはかなりざっくりと。 create table `address` ( `id` int(11), `a
このページを最初にブックマークしてみませんか?
『blog.nikuniku.me』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く