home ホーム search 検索 -  login ログイン  | help ヘルプ

find 検索

11 - 20 / 1319    [|<]  [|<]  [<]  1  2  3  4  5  6  7  8  9  10   [>]  [>|][>|]
タイトル/名前 更新者 更新日
Java/Java8u60でのラムダ式引数名のリフレクション対応を活用したクールなMapビルダーの参考URLメモ msakamoto-sf 2019-01-02 18:53:14
日記/2019/01/02/IntelliJ IDEA の雰囲気を掴む msakamoto-sf 2019-01-02 18:37:53
日記/2019/01/02/ブログとYakiBikiの今後について msakamoto-sf 2019-01-02 15:09:07
Java/IntelliJ IDEA/プラグイン参考メモ(2018-12時点調査段階) msakamoto-sf 2019-01-01 09:59:49
Java/Springでの Server-Sent Events, WebSocket 参考メモ(2018-12月頃) msakamoto-sf 2019-01-01 09:27:02
日記/2018/12/31/減量折返しポイント通過中 + 2018年まとめ msakamoto-sf 2018-12-31 21:01:39
日記/2018/12/08/Fluentd/Embulkなどデータ,ログ収集系の参考リンクメモ msakamoto-sf 2018-12-08 15:31:20
FrontPage msakamoto-sf 2018-09-09 18:42:46
プロフィール msakamoto-sf 2018-09-09 18:40:44
日記/2018/09/09/1年間のジムトレーニングを通じての感想 msakamoto-sf 2018-09-09 12:07:44
ソート項目 / ソート順     1ページ 件ずつ表示

Java/Java8u60でのラムダ式引数名のリフレクション対応を活用したクールなMapビルダーの参考URLメモ  

所有者: msakamoto-sf    作成日: 2019-01-02 18:52:57
カテゴリ: Java 

参考:

何ができるようになるか?:

    @Test
    public void java_hash_literal() {
        Map<String, String> hash = hash(
            hello -> "world",
            bob -> bob,
            bill -> "was here"
        );

        assertEquals("world", hash.get("hello"));
        assertEquals("bob", hash.get("bob"));
        assertEquals("was here", hash.get("bill"));
    }

    public static <T> Map<String, T> hash(NamedValue<T>... keyValuePairs) {
        Map<String, T> map = new HashMap<>();
        asList(keyValuePairs)
            .stream()
            .forEach(kvp ->
                map.put(
                    kvp.name(),
                    kvp.value())
                );
        return map;
    }

(via : https://github.com/benjiman/lambda-type-references/blob/master/src/test/java/com/benjiweber/HashLiteralExample.java )

なんとなくしか理解してないが、ラムダ式の引数名をリフレクションで取り出せるようになったのを活用して、key -> value をラムダ式に見立てれば、key をラムダ式の引数名として取り出せるよね、それでクールなMapビルダー作れたよ!という話らしい。
まぁ空白とか記号混じりは厳しそうなのである程度制限はあると思うが、アイデアとしては面白い。

・・・まぁ、これ使うくらいならドメイン特化したビルダー作るかもしれないけど・・・。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 18:53:14
md5:b1f1cb66a1292b4a3d7984071d6f59a5
sha1:c476d0e872c2313fa3077f1a2bcc12ebc8fd0670

日記/2019/01/02/IntelliJ IDEA の雰囲気を掴む  

所有者: msakamoto-sf    作成日: 2019-01-02 18:36:38
カテゴリ: IntelliJ IDEA 

IntelliJ IDEAの雰囲気を掴むために、だらだらとググったり、軽くHello Worldを手元で触ったり既存Mavenプロジェクトをインポートしたりしたメモ。

3行でまとめ:

  1. Kotlin, Scala, Android開発するなら鉄板。エコシステムの中枢だから。
  2. Community Edition は商用利用可能。
  3. JavaEE や Spring でガッツリ開発するなら Community Edition では力不足で、有償製品であるUltimate版を購入したほうが良い。

Eclipseユーザからの移行ガイド系:

もちろん、中にはEclipseに戻ってきた人もいるようで・・・。

機能は豊富・・・なのは当然として、ショートカットキーや補完機能が豊富。

またヘルプドキュメントもしっかりしていて、日本語サイトもバッチリ。

ぶっちゃけ、ググるくらいならその前に上記日本語ドキュメント読んだ方がよほど勉強になると思われ。

最近は個人/仕事とも、Spring FrameworkやSpring Bootを触ることが多い。
基本的にはどれも普通のMaven/GradleのJavaプロジェクトなので、読み込んで実行する分にはIDEAでも問題ない。(jarビルドの場合は。warビルドにしてTomcat等にデプロイするとなると、Community Edition ではTomcat等のアプリケーションサーバの実行が未対応っぽいので、Ultimate版が必要かもしれない)

ただし、Spring Boot のプロジェクト作成については Community Edition 版は未対応。Ultimateなら対応してる。

Spring Boot のdevtoolsも、Community Edition でなんとか使えるっぽい。

Spring開発については、公式からは Eclipse ベースの Spring Tool Suite (STS)が提供されている。

今はこれを使っているのだが、IntelliJ IDEA の、それもUltimate版になると Thymeleaf のテンプレートでThymeleafの補完が使えたり、SpringにおけるDIの依存関係のビジュアライズなど使えるっぽい。

これが結構嬉しいかもしれない。

ぶっちゃけ、Eclipse(= STS)でも問題ないっちゃ問題ない。
ただ、ガッツリ開発に集中するとなると、IDEAの細かいところまで行き届いた一貫性のあるIDEとしてのエコシステムの完成度や、キーボードショートカット・補完機能による開発(体感)効率の向上は無視できない。

言い方を変えると、Eclipse(or STS)では無料 + 開発者自身で足りてない部分をアレコレリサーチして作り込んだり対応するコストがあるが、IDEAの場合は有料の代わりにIDEA内ですべて完結するようになっている、とも言える。
価格としても2019年1月時点で Ultimate版のOrganization向けが1ユーザ/年で499ドルと、安くはないが、飛び抜けて高いわけでもない絶妙な値付けになっている。
よって本気で開発にリソース投下するなら、最高の装備としてUltimate版を購入するというのは十分有効な選択肢に思われる。

まぁEclipseでも無料で戦えるじゃん!と言われるかもだけど、年額499ドルは、無料の代わりに払う諸々のコストを札束でぶん殴って十分お釣りがくる値付けだと個人的には思われる。

例えるなら、熟練兵でゲリラ戦するならEclipseでもそりゃ戦えるけど、年額499ドル払うだけで新兵を熟練兵とまではいかずともそれなりにブーストできるわけ。
それなら最初から熟練兵に499ドルの最新兵器を与えれば、最強じゃね?という話。

一言でまとめると、金の力は偉大。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 18:37:53
md5:c8cf16df4db72a71907f94d28a20a283
sha1:d1d983ab11655317a72588780d783fb5dea1dc53

日記/2019/01/02/ブログとYakiBikiの今後について  

所有者: msakamoto-sf    作成日: 2019-01-02 15:03:01
カテゴリ: YakiBiki 

このブログのために自作したYakiBikiだが、PHP4の最後の時代に作ったこともありいい加減古い。
PHP5にキャッチアップできてないのと、それゆえに、PHP7では多分動かない。

それ以外にも機能/設計面で厳しいところも多い。例えば・・・

  • 記事の更新時にACLキャッシュを再生成するため重い。
    • これが割とクリティカルで、気軽に記事を作れない・・・。
  • 常にACLを参照するのと、生成したHTMLのキャッシュ更新が走るため、記事を表示するだけでもレスポンスが重いときが多い。
  • プレビュー画面が無いのがいい加減しんどい。
  • 記事表示画面でも編集系アイコン・リンクを出力してるが、Google Botなどがこれらを辿った結果、ときどきGoogle Analyticsで大量の403アラートが出る。
  • Markdown対応してない。

もともとYakiBikiを作るときの目標として、小~中規模IT企業における社内Wikiという活用方法を想定していた。
そのためACLに注力し、その結果としてACLのキャッシュという形を仕込んだわけだが、これがnon-DB(独自ファイルストア)と相まり、1,000件を超えたあたりから記事の更新が数秒かかるようになってしまった。
それでもプレビューがあればまだマシだったが、プレビュー機能は手抜きで作らなかったし・・・。
そうなると、個人利用でSEOも気にしたパフォーマンスそこそこ出す必要のあるブログとしては、もはや時代遅れも大概な遺物となってしまっている。

社内Wikiというか社内ナレッジサイトなら、今なら esa.io もあるし、GSuite や Office365 などでクラウドストレージ兼ドキュメントシステムもある。
タスク/プロジェクト管理やナレッジ共有 Backlog もあるしオンプレなら老舗のredmineでも戦える。メンバー構成によってはGitHub系も選択肢に上げられる。

自分自身も、働く会社が、受託系で細かくACLを気にする必要のあるSE/PG中心SIerではなく、ある程度の期間自社メンバーと一緒に働く場所に身をおいていることもあり、ACLの必要性が薄れてしまった。
そうなると、ACLを重視したYakiBikiはもうオーバースペックというか要望的にアンマッチであり、会社で使うことも将来的にまず考えられない。

で・・・じゃぁ、どうすんねん?だが、方向性としては以下のいずれかが考えられる。

  1. PHP7へのマイグレーション & ACL機能削除による軽量化 & プレビューと下書き機能追加
  2. 別のOSSブログシステムへの移行 (WPとかその他OSSのシステム)
  3. GitHub Pages への移行(= Jekyll ベースの静的サイトジェネレータ)
  4. Qiitaやはてなブログや WordPress.com など外部ブログASPへの移行

ここでどうしても死守すべき要件は次の一点。

  1. 今のサイトのURLは死守する。(はてなブックマークや、現行URL資産で参照している外部サイトの価値を保全したい)

全く新しいサイトを新規作成して、そこで新しい記事を書いていく・・・のは、それはそれで問題ない。
が、「今のサイトのURLを死守」というのは別のOSSブログシステムやGitHub Pages(Jekyll)や、ましてやはてなブログ/WP.comでは実現できない。
(多分静的サイトジェネレータの一部では .htaccess 調整でリダイレクト対応とかできるかもしれないが、現行URLは1,000を超えており、.htaccessでそれだけのエントリのrewriteを管理するのは不可能)

つまり、「今のサイトのURLを死守」=「今のサイトを引き続き独自アプリでメンテしてく必要がある」ことを意味する。

まぁ実際問題、"/"区切りの記事の階層化とか、プラグイン記法によるナビゲーションや階層化記事の一覧機能など、機能としてはそこそこ便利だし引き続き使いたい機能はある。
これを完全に捨て去るのは、個人的にも惜しい。

外部ブログASPについては・・・

  • プログラミングの記事であればQiitaで申し分無いが、ちょっとしたメモや、プログラミング/IT系以外の記事については書けない。よって、どうしてもQiita以外も併用する必要が出てくる。
  • はてなブログは、無料版はキーワードリンクが厄介。CSSとかで事実上無効化はできるが・・・。広告も消すには有料版が必要。ただ、有料版といえども、そもそもサイトの表示が(個人的な主観だが)微妙に重いときもあり、個人的に使うときに「個人的に好み」かと言われるとイマイチなところがある。
  • WordPress.com : 論外。
  • どちらにしても死守要件は適用できない。
    • 一応はてなブログではWP/MTの記事をインポートできるようにはなっているが、そもそも現行記事データは現行Wikiフォーマットの固まりでインポートしようが無いし、WP/MT形式のエキスポート機能自体が無いので作らないといけないしで超面倒臭そう。

つまり死守要件は適用できないので現行サイトには使えないし、新しい記事についてだけ外部ASPを使おうとしてもそもそも個人的に気に入ったASPが無い。

GitHub Page など静的サイトジェネレータへはどうか?これも .htaccess のrewrite問題 + 過去記事互換性問題が立ちはだかるのと、新しい記事についてだけ~というパターンでも、やっぱり静的サイトジェネレータだと執筆環境がWebではなくて、サイトジェネレータ + アップロードという手間がかかるので個人的には厳しい。

結局のところ、現行サイトのURLと記事生成の仕組み(現行Wikiシステム)を維持する以上、何を選んでも「現行システムのPHPマイグレーション」は避けられない。
プラス、現行Wikiシステムは今後も使いたい。
となれば、YakiBikiの軽量化 & モダナイズが総合的には最も満足度の点からも、コストの点からも優れている。(結局マイグレーションしなければいけないなら、その見返りとして現行Wikiシステムのメリットを享受し続けたい)
ただし、引き換えに、また5~10年後に同様にマイグレーションの必要が生じる。
が、まぁ、それはそれで、いいかな・・・と。なかなか難しいところはあるけれど、現行資産の保全が割と優先度高いので。

現行 "/view/(数値)" URLを Permanent Redirect で "/view/(数値).html" にしておいて、もしものときの静的HTMLアーカイブ対応に備えておく、というのも考えたが・・・
まぁ、しておくことはしておくが・・・
次回または次次回のマイグレーション時の検討課題として残しておく。

要するに、超長期的には静的HTMLアーカイブした上で GitHub Pagesなどにごっそり上げる方向で考えたい。
しかし、そのための中期~長期のURL移行期間が必要なのと、その数年~十年単位の間での技術革新によりまた選択肢が増えることもあり得る。
そのため短期的にはPHPマイグレーションを主目的にしつつ、超長期に向けた移行期間への備えとして軽量化&モダナイズを実行し、いざというときの静的HTMLアーカイブに対応しやすいようにシンプルなサイト構成となるよう改造する。

軽量化&モダナイズ&機能強化のアイデア例:

  • ACL機能削除, グループ機能削除
    • マルチユーザは残しておくが、単に「執筆者」以外の機能は持たず、記事の公開アクセス範囲には関連しない。記事はワールドワイドに公開するか、下書きか、どちらかで、下書きについても執筆者であれば全員が見れる。
    • このへんを削れると、性能面でだいぶ改善されるはず。
  • 画像/ファイル/URLアップロードについて、検索や最新一覧での表示対象外にしたい。
    • 今は一覧に出てしまうので、気軽に画像やちょっとしたファイルをUPできない・・・。それか、完全にdiscloseして、そういうのは外部ストレージに回したい・・・。
  • Markdown対応、現行Wiki記法の細かなバグ調整など
  • 下書き・プレビュー機能
  • カテゴリ管理や編集時の設定のモダナイズ
  • 記事のpermanent url を "/view/(数値).html" に変更
    • これが超長期に向けた、中長期の移行を見据えた短期的に実施可能な布石。
  • 検索機能を単純な一覧化 & タイトルやカテゴリ検索を、フロントエンド側のJSフィルタリング機能として実装しなおす。
    • フロントエンド側にカタログデータを出力して、ブラウザJS側でタイトル/カテゴリフィルタリングする形にしても実用上問題ない。SEOとしてそこまで追っかけてほしいわけじゃないし。
    • つまりサーバサイドレンダリングとしては単純なWiki一覧が出てくればよくて、まぁソート機能付きならベスト。で、検索というかフィルタリングとしてはブラウザのフロントJS + フロント用のフィルタリング結果を返すAPIで動的に行い、それは別にSEO考えなくていいのでOK。という形にする。
    • こうすることで、将来静的HTMLで凍結しやすくしておく。

→ここでの問題として、「現行、ワールドワイドには非公開の記事をどうするか?」問題が残っている。
これについては、現行のデータを洗い出した上で、非公開記事データは現状自分しか見れない状態なので、HTML or 記事そのままのテキスト状態で、Google Driveに入れておく、という程度で問題ないと思う。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 15:09:07
md5:bc5c6975d1af1bef87cec22097a450b4
sha1:0923bff3a91adf384f25ec296e3dab9048662085

Java/IntelliJ IDEA/プラグイン参考メモ(2018-12時点調査段階)  

所有者: msakamoto-sf    作成日: 2019-01-01 09:59:19
カテゴリ: IntelliJ IDEA Java 

2018-12時点で、Eclipseでよく使ってる(というか必須の)プラグインでInteliJ IDEA版がどうなってるか軽くググった参考メモです。
リンク先について、Community EditionでもOKなのか商用版のみかは検証してません。調査段階のメモなので、今後実際に動かして確認してくかもしれません。

TestNG: JUnitよりはTestNGの方が実用的でシンプル、使い勝手が良いので愛用してます。

  • TestNG - IDEA Plugin
    • http://testng.org/doc/idea.html
    • IntelliJ IDEA 7 からIDEA本体にバンドルされてるようです。2018-12時点のCommunity Edition最新は 2018-3 でだいぶバージョン上がってるので、多分大丈夫じゃないでしょうか。

CheckStyle: IDEAだと、checkstyle.xml をソースコードフォーマッタにも反映できるのが良さげ。Eclipseだとここ、分断されてるので checkstyle.xml とは別に Java Editor の Code Formatter を手動で揃えないといけないんですよね・・・。

  • CheckStyle-IDEA - Plugins | JetBrains
  • Java - IntelliJ IDEAにCheckStyleプラグインを導入し、フォーマッタに反映する - Qiita
  • Google Java StyleをCheckstyleとIntelliJ IDEAに適用する手順メモ | takemikami's note
  • Google Java Style Guide
    • https://google.github.io/styleguide/javaguide.html
    • こちらが Google からの Java Style Guide ですが、わりと無難で最大公約数的な内容なので、受け容れやすそうです。一行100文字の制限だけ個人的にはちょっと厳しいかも?
    • ただ、ところどころにexception扱いがあるなど、checkstyle.xmlで完全にカバー・制約付けするのも難しそうなところもあるので、100%カバーは難しいかもしれません。

一個気になる機能として、Eclipseのcode formatterでは以下のような形でフォーマッタの適用範囲外を設定できる機能があります。

// @formatter:off
...
// @formatter:on

checkstyleというよりはIDEのフォーマッタの機能になりますが、同等なものが IntelliJ IDEAにあるか若干気になりました。

→ありました。2018年最新版ならまず問題なさそう。

FindBugs or SpotBugsプラグイン → FindBugsならプラグインあり。SpotBugsについてはリクエスト中。

とりあえず、あるのはわかったので、後日時間があれば、実際に動かしてみたい。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-01 09:59:49
md5:ee5c6c80c76cfcba7a77afe02eca4e2f
sha1:d2e9b36b7f1b219387e971f97a2a70750e4ed3c3

Java/Springでの Server-Sent Events, WebSocket 参考メモ(2018-12月頃)  

所有者: msakamoto-sf    作成日: 2019-01-01 09:25:10
カテゴリ: HTTP Java Spring Framework 

Springでの Server-Sent Events, WebSocket 参考メモ(2018-12月頃)

SseEmitter版:

WebFlux版:

SseEmitter版の方が簡単そう。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-01 09:27:02
md5:4a68854273f3da4a4e6743410b9035cc
sha1:b3f0d3bfbd525ab43f6a4e3ef465ec59d1c39907

日記/2018/12/31/減量折返しポイント通過中 + 2018年まとめ  

所有者: msakamoto-sf    作成日: 2018-12-31 20:37:13
カテゴリ:

9月1日より始めた減量だが、4ヶ月でおよそ10kgの減量に成功した。現在80kgを切りつつある最中。
BMI標準体重は71.3kgなので、ようやく折り返しポイント通過中、という状況。
食事制限と週3日のジムでのマンツーマントレーニング(20分程度の筋トレ)を続けている。

正直なところ、荷重トレーニングについてはここ2ヶ月ほど重さが変わっていない。デスクワークで日常的に筋肉を使っていないこともあるせいか、どうも、あるレベルの重さ以上にはなかなか上げられない。
それでも減量は続いていることから、筋肉が増えるというよりはやはり脂肪を減らす方向が維持されていると考えるべきか。
実際、去年末~今年前半の筋肉を増やす方向のトレーニングでもあまり目立って筋肉が増えたわけではない。子供の頃から運動してなかったこともあり、筋肉がつきにくいのだろうか。

ともあれ、今のペースを維持することにまずは専念して、折返しを走り切ることに集中したい。

2018年は個人のブログはほとんど書けなかった。
まず仕事としてのアプリケーション開発に燃え尽きてしまったのと、今年の前半~夏は特に体幹トレーニングにシフトしてからは強度が強すぎるせいか土曜のトレーニングのあとは日曜まで倒れ込む有様で、あまりプライベートな休みを勉強/プログラミング/ブログ書きに割くことができなかった。

代わりに、ぐったりしてる土曜のトレーニング後や日曜などにアニメはたくさん視聴できた気がする。正直、ここまでアニメを観まくったのは人生初だったかもしれない。pixivに没頭する時間はその分減った。

また、奈良・飛鳥旅行と恐山旅行で、日本仏教の始点と終点(というか霊場としての北端)をこの目で見てこれたのが一番のハイライトと言える。
どうも、この2つの旅行で仏教については「やるだけやった」感が出てしまい、探究心が急降下してしまった。
とはいえ信仰が無くなるとかそういうことではなく、あとは実践あるのみ、と踏ん切りがついたというべきか。

来年については、引き続き減量を続ける。一応BMI標準が目標だが、いけそうなら70kgを少し切りたい。医者からは「40歳になるまでに学生時代の体重に戻さないと大変なことになるよ」と脅されているが、大学時代のみならず高校時代まで含めれば、67kgあたりまで削れたときがある。よって、そこまで削れればこの上ない成果といえる。が、まぁそもそも今のトレーニングは「太った脂肪を落とす」内容なので、標準体重まで到達した後にさらに脂肪を落とすのがどれほど健康やトレーニング内容に影響するか、そのときにまた検討することになるだろう。

標準体重到達前後から婚活も再開したいし・・・。

仕事については今の所モチベーションは保たれている。が、さすがに今年は一つのアプリ開発に没頭しすぎたので、来年は別のアプリ開発や、仕事で必要なインフラ周りの拡張作業、あとはレガシーのクリーニングなどでちょっと趣向を変えて仕込みの年にしたい・・・できるといいなぁ・・・というところ。

あまりプライベートタイムを費やして新しいアレコレに挑戦しよう、という欲は無い。仕事と趣味のオーバーラップ領域が多いので、仕事で必要になったことを趣味とプライベートタイムに昇華させるサイクルをうまく嵌め込んで行ければいいなぁ、という感じ。新しい言語やFWにアレコレ手を出すというよりは、仕様とか実装の調査などが多くなりそう。また、そもそも調べ物でお金をもらいたくて今の会社に入ったという面もあるので、仕事として調べ物が必要となればまさにそれこそが趣味の実践となる。

そんな感じで、来年は肩の力抜いてく感じで。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2018-12-31 21:01:39
md5:3cf049cb3a740aa626ad58020e58eefc
sha1:1f44f1fb18110a38ea8af8e145811ff4efcae8bc

日記/2018/12/08/Fluentd/Embulkなどデータ,ログ収集系の参考リンクメモ  

所有者: msakamoto-sf    作成日: 2018-12-08 15:30:40
カテゴリ:

使い方とか、雰囲気などわかる参考URLのメモです。

Fluentd関連参考

Embulk : Fluentdと開発者が同じで、Fluendtがstreamなら、Embulkはbulk転送。

なお、Datadog/Mackerel/NewRelic はログ収集ではなくてモニタリングサービス(メトリクス収集など)なので、データ・ログ収集とは全然違う分野のサービス群。
参考:


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2018-12-08 15:31:20
md5:c77f81c39b46135e824dea2ec3d34e34
sha1:94692ad52d00b3988ac9b247df5cdde418a20c7f

FrontPage  

所有者: msakamoto-sf    作成日: 2008-11-23 18:22:11
カテゴリ:

Glamenv-Septzen : ぐらめぬ・ぜぷつぇん

msakamoto-sf こと 坂本昌彦 によるプログラミング技術を中心としたブログ兼Wikiです。

Twitter: @msakamoto_sf

GitHub:

Qiita:


使用しているツールの制約上、コメントやトラックバックは受け付けられません。
本コンテンツへのご意見もしくはコメント投稿用アカウント申請については、Eメールにて下記アドレスまでご連絡下さい。

sakamoto.gsyc.3s@gmail.com

なお、2001 - 2003年にかけて作成し、Niftyホームページ上にて公開していたコンテンツについては以下を参照して下さい。*1

風晶のC言語プログラミング
https://www.glamenv-septzen.net/nifty/index.html
2010年頃作ってた英語出張版
https://www.glamenv-septzen.net/en/
*1: 技術・非技術系問わず内容が非常に古くなっています。坂本の大学生時代の活動内容としてメモリアルページとして利用して下さい。

プレーンテキスト形式でダウンロード
現在のバージョン : 14
更新者: msakamoto-sf
更新日: 2018-09-09 18:42:46
md5:3a4778eb34655509d8dc7b8dbeb77dc7
sha1:93f5ace5eba2d09004a80fb9e9812dca76da30d7

プロフィール  

所有者: msakamoto-sf    作成日: 2008-11-24 01:04:10
カテゴリ:

msakamoto-sfのプロフィール

本名
坂本昌彦, 1981年生まれ
出身地
千葉県香取市*1
主に使うプログラミング言語
PHP, Java

PHPは趣味です。仕事ではJavaをメインとして雑食性です。C(Windows, UNIX)/VB/Ruby/Perlなどの使用経験が有ります。

  • 2004/04 - 2009/07 : 東京都立川市内のソフトハウスでPGとかSEなどに従事。
  • 2009/09 - 2009/12 : 東京都内にてポータルサイトの開発に従事。
  • 2009/12 - 2011/05 : 無職
  • 2011/05 - : 東京都内のWebアプリケーション脆弱性検査業務に従事。

GitHub:

Qiita:

XhwlayというPHPライブラリと、このサイトでも使っているYakiBikiというWikiクローンをマイペースで開発しています。

座右の銘

BRAIN VALLEY (瀬名秀明, 角川書店), 下巻 382p(ハードカバー版)より:

この世で最も厄介な人種は科学者だ。
精神は小学生より幼稚であるにも関わらず、人一倍プライドと体面を気にかける。
彼らは決して社会に出してはいけない。
山奥に隔離し、ふんだんな機材と試薬と実験動物を与えて飼い慣らすに限る。
そして時々、お前が世界で一番偉いのだと声をかけてやるのだ。
そうすれば100年に一度くらいは有益な成果を上げるかもしれない。
だがいずれにせよ、愚かで小賢しい存在であることに変わりはない。

本書中に登場する、とある人物からの視点。
「科学者」→「プログラマ」なり「SE」なり「IT技術者」なり「ギーク」なりに置換する。
トラウマ級に精神に刻み込まれた、戒めの言葉。

読んだ本

読書 参照

好きな絵師

  • 智内兄助
  • 清原啓子(銅版画)
  • 松井冬子
  • 冬目景(漫画家)
*1: 旧佐原市

プレーンテキスト形式でダウンロード
現在のバージョン : 9
更新者: msakamoto-sf
更新日: 2018-09-09 18:40:44
md5:da25f3b258f59d4b373193eb8bf8cb82
sha1:97b826abdee4a6383fa8ef68bddea93d28f6a037

日記/2018/09/09/1年間のジムトレーニングを通じての感想  

所有者: msakamoto-sf    作成日: 2018-09-09 11:25:41
カテゴリ:

2017年10月頃から、近所のコナミスポーツクラブのジムに通い始めた。

  • 2017年10月~ : 6週間のダイエット・トレーニング("バイオメトリクス"), 週三回, 毎回30分くらい, 93kg -> 89kg
  • 2018年12月~2月くらい? : 4週間の筋肉強化トレーニング("V-BODY"), 週二回, 毎回30分くらい
  • 2018年3月くらい?~7月 : トレーナーとのマンツーマントレーニング("パーソナルトレーニング"), 週一回, 毎回30分くらい

最初のダイエット・トレーニングでなんとか90kgを切れたが、その後のトレーニングは筋力強化のため、体重は減っていない。トレーナーのその時点でのおすすめとしてはダイエット・トレーニングの後に筋力強化に進む人も多いとのことだったし、筋力強化系のトレーニングはやったことなかったので、実験目的で挑戦してみた。

体重についてだが、2018年前半で数回福岡出張に行ってそこで散々飲み食いしてしまったため、2018年5月頃に92kgまでリバウンドしてしまった。
その後、6-7月にかけて91kgくらいまで戻せたが、91kgを下回らない日々が続いている。

全体的な感想としては、どうも筋力強化が思ったよりも体に負担がかかってしまい、まずはダイエット・トレーニングが先のようだと感じている。

というのも、5月くらいからパーソナルトレーニングで体幹トレーニングを取り入れてもらったのだが、これがかなり汗だくで、暑くなってくる6月くらいから、トレーニング終わったあとは精根尽き果てた状態になっていた。暑くなってくるとジム内も冷房が入るが、この冷房の風が汗だくの体に堪える。
日によってはトレーニング終了後は悪寒や震え、頭痛などでグロッキー状態になったこともあった。

しかも、トレーニングが終わったあとに筋肉痛とともに、頭痛に襲われるようになった。これは筋力強化のトレーニングのときからも時々あったのだが、何が弱るかというと、土曜日にトレーニングに行ったあと、日曜日が筋肉痛と頭痛により、最低限の買い物以外は基本、家で寝込むかアニメ見て終わり、という状況になってしまった。読書やプログラミングなどの活動が全くできない状況だった。

ついには、7/28 の昼間のトレーニング終了後にどうにも悪寒が止まらず更衣室でうずくまってしまい、救急搬送されるに至った。(救急車が到着する頃にはもう大分回復していて、病院で点滴打ってもらったらすぐ帰れたのは幸いだった)

心配したトレーナーにより、8月一杯は強度を落として弱めのトレーニングに切り替えてもらい、それによりトレーニング後の頭痛も無くなった。

また、体幹トレーニングを導入した5月くらいから、トレーニング前に測っている血圧が高めになっているのもトレーナーから指摘された。どうも、体幹トレーニングだと「踏ん張る」動きが多くなる都合で、血圧が高くなる傾向があるらしい。(個人差もあるようだし、自分の場合、高くなるといっても最高140くらい)

そのため強度を落とすとともに、体幹トレーニングも5-7月まで3種目くらいやっていたのを、0か、1種目程度に変更された。

結果、8月一杯の血圧を見てみると少しずつ最高血圧が低くなっているので、やはり体幹トレーニングが血圧を高める一因の可能性が高いようだ。(全体的にトレーニングの強度を弱めてるので、体幹トレーニングだけが要因とは言えない。また、そもそも夏の暑い中をジムまで移動して、その後数分の着替えで急な冷房で体が冷やされるので、その影響も考慮したい)

救急搬送の次の週にトレーナーと今後のメニューについて打ち合わせしたときに、前述の体幹トレーニングと血圧の関係を聞かされた。また、念の為医者に相談してもらうようトレーナーから言われたため、近くの糖尿病・高血圧など成人病メインの内科クリニックにでかけて健康相談をした。医師からは、筋肉強化よりは減量を進められた。血圧についてはまだ薬が必要なほどではないとのこと。ただ、血圧についてはジムや病院などだとどうしても緊張状態が入ってしまい、平常時の血圧にはなりづらい。なので、家で毎日測ってみてね、と言われたので3千円くらいのシンプルな血圧計を買ってみて、なるべく毎日、朝と夜に測るようにしてみたところ、なるほど、確かにジムで測るよりも若干低い値になっていた。

ということで、そのへんもトレーナーと共有してみて、ここはやはり減量だろうということで、9月からまたダイエット・トレーニングを始めてみた次第。

ここまで1年ほどジムで有料トレーニングを受けてみたが、90kg台の体重の状況では、やはり減量トレーニングが最も優先すべき事項であり、また効果も出やすいようだ。

一方で筋肉強化については体重90kg台の状況ではあまり意味が無かったようにも思える。というのは、もともと筋肉を使わない日常(デスクワーク)なので、トレーニングをしないとあっという間に筋肉が落ちてしまう。
実際、救急搬送された次の週に体脂肪率を計測したら、筋肉量が28kgと出て、その後トレーニング強度を下げて1ヶ月経ち、ダイエット・トレーニング開始時にまた体脂肪率を測定したら筋肉量が 27.7 kg まで300g落ちていた。これは2018年最初にやった筋肉強化トレーニング4週間コースの1回分で増量した分に等しい。

つまり、自分の今のライフスタイル・ワークスタイルにおいては「日常に支障が出ない範囲のトレーニング(救急搬送後の8月のトレーニングレベル) 」では、「血圧や日常に支障が出るレベルのトレーニング」でつけた筋肉が消えてしまう、ということになる。

言い換えると、血圧や日常に支障が出るレベルのトレーニングで増量した筋肉は、その後の血圧や日常に支障が出ないレベルのトレーニングでは維持できない。(少なくとも2018年前半の自分の体では)

言い換えてみれば「そりゃそうだ」という話で、成長期ならいざ知らず、思春期~成人までを通じて運動嫌いで運動らしい運動をしてこなかったメタボの30台後半なのだから、たかだか半年ほどで増量した筋肉がそう楽に維持できるものでもない。

実際、今日はこうしてブログを書けているが、5~7月の救急搬送まで、土曜日のトレーニングのあとはグロッキー状態でブログを書ける状態ではなかった。そこまでして増量した筋肉が、「体に無理のない」トレーニング1ヶ月で300gも消えてしまうのだから、これはもう、無理筋というものだったのかもしれない。

ということで、兎にも角にも減量最優先という戦略に切り替えてまた少し実験を続けてみて、自分の体がどう反応するか?特に、去年のダイエット・トレーニングでは、それまでジムに行ってなかった状態で始めたが、今年は1年ほどトレーニングに慣れて筋肉も一応増えた状態で始まるので、それでどう違いが出るかを検証してみたい。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2018-09-09 12:07:44
md5:073c66341f40a305a8b18888f24f4aeb
sha1:e381e2b5e5aa557e05cd8cdf63a483c3d4586a28