なぜいま、筋肉エンジニアが増殖しているのか?
みなさん、筋肉エンジニアってご存知でしょうか?
筋肉をエンジニアリングする人?
(何だそれ)
誤解を恐れずに説明すると、
「通常エンジニアリングで解決すべき課題・問題を自らの筋肉、あるいは筋トレをして鍛えたその精神で解決する人」
のことです。
では、なぜいま筋肉エンジニアが増殖しているのでしょうか。
あくまで想像ですが、その理由は3つあります。
運動不足解消
1つ目。これがもっとも有力な説です。エンジニア(特にシステムエンジニア)は長時間の座り作業を日々繰り返しています。
それによって、筋力が衰え、心肺機能が低下。腰痛や病気がちな体質に一直線です。
そんな生活を定年まで続けて行くのはしんどいことに気づいたエンジニアたちが、
筋肉を鍛え腰痛と戦い、運動をすることによって心肺機能の向上を目指したのです。(たぶん)
異性への興味の目覚め
2つ目の説です。これは、できれば間違いであってほしいところですが、エンジニア(特にシステムエンジニア)は、近年急速に注目を集めて
来ており、フリーランスになったり起業をしたりしやすい職業で、憧れる人も増えてきました。男性中心の職種でしたが、最近では女性の方も
増えてきており、いままでではなかった異性との交流が始まっています。
いままでは、女性との交際などは夢のまた夢、女性と話すことすら難しかったエンジニアたちは考えます。
「ほかのエンジニアと差別化するためには何をしたら良いのだろう?」と。まさか自分の得意なスキルを磨いて、「〇〇の処理速度を3倍にしたんだよ~♪」
と話しても興味を持ってもらえないことくらいは分かっています。かと言って、人と話すのは苦手だし、トークで勝負するのは無理だなと。
そこで気づきます。「そうだ! 女性は細マッチョが好きだっていうし、筋肉があれば自分が話さなくてもモテるんじゃないか?」
こうして、女性と交わる機会を得た内気なエンジニアたちは、筋トレで鼻息を荒くするのです。(たぶん)
さらなる知力への欲求
3つ目。近年の研究では、知的な能力を高めるためには、運動が最も有効であるということが分かっています。
エンジニアとは知的労働者ですので、効率よく仕事を行うためには、高い知性が必要なのです。
運動することによって高い知性が手に入れられるのであれば、やらない手はないでしょう。
基本的にエンジニアは創造的活動や、問題解決が好きです。そのために、様々なツールを活用したり
日々勉強をしていますが、現代においては、自分の能力を高めるために筋トレを行うのです。
さあ、筋肉エンジニアが増殖している理由について、私なりの推測を行ってみましたが
エンジニアの生態はまだまだ謎が多く、かつ一様ではないのです。
実際に自分で体験をしてみることによって、筋肉エンジニアの気持ちがわかるかもしれません。
いずれにせよ、健康的なエンジニアが増えるのは良いことですし、女性側からしても良質な筋肉が見られるのは
嬉しいのではないでしょうか。(知らんけど 笑)
今回は男性側の筋肉エンジニアについて考察してみましたが、最近では女性の筋肉エンジニアさんもいらっしゃるようですね。
引き続き観察していく必要がありそうです。
media queryを利用してスマホ対応するシンプルな方法
ホームページを作りたいなと思い始めて、HTMLを手書きでガシガシ書いていたわけですが、ふと。。。。。。。
普通、アクセスの大半はスマホからじゃね?
ということに気づき、、、
PC版も完成していないのに、急遽スマホ対応することになりました。
いろいろ調べてみた結果、ページを分ける方法もあったみたいですが、今回はCSSのmedia query(メディアクエリ)で対応してみたいと思います。
例えば、リクエストを送ってきたブラウザ側の画面の幅をもとに、適用するスタイルを変更する方法。
@media screen and (min-width: 200px){ li{background-color: blue;} }
今回の場合だと、 @media のあとに、スクリーンメディアのタイプを指定しています。これは、PCやスマホなどのスクリーンのことです。他にもプリント(印刷)する場合などを指定することができます。
そして and 条件でつないで、 min-width: ○○px と指定することで、○○px以上のときに、という条件を指定することができます。
他にも、いろいろな条件を指定することができるので、興味がある方はぜひ調べてみてくださいね。
AJAXを使ったときにHTTP status 400 で苦しんだ話
Javaのアプリケーションを作成していたら、AjaxのリクエストがHTTP status 400 BAD REQUEST になって苦戦した。
他の環境では同じリクエストが使えるし、なんなんやろ?と頭を悩ませること2時間・・・
Tomcatのログを見ていたら、「RFC」とかいう見慣れない文字が出現。
原因は、URLパラメータに設定してた、jsonの「{」という文字が、あるバージョンのTomcatで利用できないからだった。
バージョンが違うから別の環境だと問題なく動いていたらしい。
回避策としては2つあるらしい。
1. Tomcat側でその文字を利用可能にする。
2. クライアント側で、URLエンコードする。
セキュリティとか詳しくないけど、Tomcatの設定を変えるのは危ないという勘を信じて、
クライアント側でURLエンコードすることにして一件落着。
ミドルウェア系全然詳しくないから勉強せねば。。(得意な人に任せようかな。)
Go言語(Golang)でHelloWorldを出力してみた
最近(少し前から?)話題のGo言語に入門してみました。
最終的にはWebアプリを作る予定ですが、一旦言語自体のお勉強ということで
とりあえずお約束のHelloWorldを標準出力してみようと思います。
この記事全然おもしろくないな
ちなみに、
- windows8.1(新しいパソコン欲しいぃ)
- go1.10.1
はい。とりあえずこんな感じのコードを書いてみました。
package main import "fmt" func main(){ fmt.Printf("HelloWorld\n") }
これを hello.go とかっていう名前で保存して実行する。
実行する方法は実行ファイルを作成してから実行するか、実行ファイルを作成せずに実行するか選べる。
実行ファイルを作成する
>go build hello.go >hello
実行ファイルを作成しない
>go run hello.go
JavaのList型でオブジェクトの参照渡しを回避する方法(値渡しをする方法)
Listオブジェクトを参照渡して記述していた例
久々にJavaのコードを書いてみた。 こんな感じのコードでListのコピーして値を渡して、その後値を消したら渡した先でもデータが消えてた。
import java.util.* public class クラス名{ public static void main(String[] args) { List<String> str1 = new ArrayList<String>(); List<String> str2 = new ArrayList<String>(); str1.add("a"); str1.add("b"); str2 = str1; str1.clear(); } }
いわゆる、参照渡しっていうやつですね。 まぁ具体的には、ループ処理の中でListオブジェクトをただの入れ物として使って次の処理のときには値をclearしようと思ったら今回の現象に遭遇。
で、どうするかというとインスタンス生成時のコンストラクタにオブジェクトを渡してあげればよいみたい。 以下参考
import java.util.* public class クラス名{ public static void main(String[] args) { List<String> str1 = new ArrayList<String>(); str1.add("a"); str1.add("b"); List<String> str2 = new ArrayList<String>(str1); str1.clear(); } }
これで参照渡しではなくなったので、安心してオブジェクトの値をclear出来る。
カルディでJanat(ジャンナッツ)という美味しい紅茶を買ったらペットボトルの紅茶が飲めなくなった話
普段節約生活を心がけているからカルディ(=お菓子とか高いイメージ)とかはあんまり行かないんだけど、たまには美味しい紅茶を飲みたいし、箱で買ったら安上がりになるんじゃないかと思って紅茶を買ってみた。
私は舌がアホなので味がどうとかは表現できないんだけど、いい香りだな~くらいは感じた。
会社に行くときも水筒に入れて持っていって節約生活をしばらく続けていて、毎日1Lの紅茶を作っても全然茶葉が無くならないし、いい買い物した~とか思ってた。
それでたまたま朝忙しくて(=寝坊して)紅茶を作れなかったから、仕方なく会社で某ペットボトルのストレートティーを久しぶりに買って飲んでみた。
そうしたら、前は何も感じずに飲んでたのにあまりの不味さに戻しそうになってしまった。誇張じゃなくほんとに戻しそうだった。
結局何が言いたいかというと、良い物は何がどういいのか説明できないけど、少し質が落ちたものに触れたときに不快感を覚えるようになってしまうということ。
これがいいことなのか悪いことなのかの議論をするつもりはないけど、人間が「快」よりも「不快」に敏感だという知見を得られたし、「不快」の基準は絶対的ではなく、相対的なのかなと感じた。
結果的には安く美味しいものに触れられてるからいいんだけど、あんまり良い物に囲まれてる生活は質を落とせなくなる危険があるから気をつけようと思う。
たまには今回みたいに技術じゃない話題も書いて行こうかな
DBのテーブルは分けよう(いや分けてくれ)という話
タイトルだけだと何を言っているのかまったくわからないだろうからちょっと具体的に書く.
例えば,人の情報を保持するテーブルを作るとして,以下のような項目を持たせたい.
個人情報テーブル
- 個人ID
- 個人名
- 年齢
- 所属グループ
こんなの簡単じゃんと思って普通に一つのテーブルにまとめる設計を見たわけなんだが,
所属が複数あったらどうする??
カンマ区切り??
所属1, 所属2.... とカラムを追加する??
それでいいと思った人はマシュマロでも食べて,お風呂入ってきてくれ.
テーブルの持ち方なんだけど,こんな感じにしたらメンテナンスが楽になりそうだと思わない??
個人情報テーブル
- 個人ID
- 個人名
- 年齢
グループテーブル
- グループID
- グループ名
対応表テーブル
- 個人ID
- グループID
対応表があればSQL発行時にもテーブル結合するだけでいいし
もっといい方法があったらぜひ教えてください.