menu
阿波銘木 公式ブログ

有限会社 阿波銘木 公式ブログ

山へ再び 原木仕入れ(^-^)/ 臼と杵の阿波銘木です。

新年の挨拶もそこそこに1月も終わります。

31日の今日は皆既月食、当社の窓からも神秘的な姿を観ることができました。

阿波銘木の空にも”スーパーブルーブラックムーン” ( T-T)ウルウル

 

今週はとても寒い日が続き2日前の29日も登別は冷たく凍り、滑るように山へ行ってきました。

昨年末は一番大きなが予想外な売れ行きで、今年の分に乾燥させていた荒削り材を急所仕上げなければならない展開となりました。

嬉しい悲鳴ではありますが、今年は十分な在庫に囲まれゆとりをもって年末を突っ走ります!。

しっかし山は寒かったです、ご覧のとおり ↓ 小川さんの顔も引きつり鼻水も( ̄ii ̄)ズル。

杵材、餅臼や机上名札表札材も買い付け、写真もそれなりに撮ったのですが、手が凍えてほとんどピンボケ状態でした(゚ーÅ) 。

ドカンと工場に運ばれてきたときにはバッチリ撮影して太くて大きくて魅力的な原木を紹介しますね!!

 

category : 近況 author : 大住 美春

フロントエンドとサーバサイドの切り分け

新年明けましておめでとうございます。

今年もよろしくお願い致します。

 

webシステム担当です。

 

さて、当サイトは昨年末にSymfony4へのバージョンアップを行いました。

その後、大きなトラブルもなく稼働しているようです。良かった^^

 

僕自身なのですが、現在Productを2つ持っています。

 

1つは新宿で上流工程を担当している案件。

もう1つはRuby on Rails5Reactを使用してのWebアプリケーションの開発になります。

 

ネイティブで動作するソーシャルゲームが普及した流れなのかもしれませんが、現在はWebアプリケーションでもフロントエンドとサーバサイドで真っ二つに作業を分担するスタイルが流行っています。

現在、Ruby on Rails5とReactで開発をしているProductもRuby on Railsは完全にAPIに徹しており、ReactのほうでAPIの呼び出し、受取り、DOMの描画を行っています。

 

ぶっちゃけてしまうと、このスタイルだと1人では限界がありますね^^;

僕もソーシャルゲーム出身なので何も言えませんが。。。

 

今までのようにサーバサイドからViewをレンダリングする形だと、サーバサイドからフロントエンドへという一通りの流れがあったのですが(非同期通信は別です)、そこを分けてしまうと完全に1つ1つの機能が疎結合になってしまい、1人では管理が極めて難しい印象を持ちます。一連の流れがなく機能のぶつ切りになってしまうと一呼吸ついてしまうのが原因と思っています(もちろん疎結合なのでトラブルの際は場所を特定しやすいという圧倒的メリットはあります)。

 

また、考え方にもよりますが、Reactのcomponentを各ページ中のデザイン単位で切ってしまうと1ページを描画するだけでも何ファイルものjavascriptファイルが出来てしまいます。

このあたりはエンジニアのスタイルもありますが。

 

ちなみに僕はReactに関してはページ単位で分けているのでclass(es6)のほうがfatしてしまうことがあります。もちろん共通部分は外に抜き出します。

それでもrenderメソッドの為だけにファイルを分けられるとちょっと管理する自信がないですね。。。

ファイル数が膨らみ過ぎます。

 

もちろんチームを組んでサーバサイドとフロントエンドのエンジニアがそれぞれ確保できるのであれば何の問題もないのですが。。。

 

React自体、Facebook社が作ったエンジンで、「もうDOMを追いかける作業はしたくない」というスタンスには僕も賛成です(jQueryもうヤダ^^;)。

ただ、これが都会ではなく地方だとどうなるのでしょうか?

 

唯でさえエンジニアは枯渇している状態です。それが地方だと尚更です。その環境下でサーバサイドはAPIを呼ぶだけにしてほしいという設計が上がってきたらまず無理だと思います。工数が取れません。

無理じゃないかもしれませんが僕は多分引き受けません。

 

結局、都会では最新の技術を、地方のエンジニアはWordPressで構築するという流れに拍車がかかるのではと思っています。

 

WordPressは素晴らしいエンジンですが、WordPressしか出来ないのに自分はエンジニアですという人が地方にはどんどん溢れていくのではないでしょうか。

 

「WordPressを使えばWebサイトが出来ます」という方をエンジニアと呼べるのでしょうか。

それはWordPressを使えるというだけでエンジニアではないと思っています。

それならホームページを構えたいという方にWordPressの本を紹介するほうがよほど親切だと思います。

もちろんWordPressのプラグインなんかを構築するレベルの方は話が別です。

 

ちょっと愚痴になりましたが、今の流れだとAll In Oneで請け負ってる方は大変になるなというだけでした^^;

 

ちなみに、ReactもAngularJSもvueJSもとても素晴らしい開発エンジンです。

ただ1人での開発だと、サーバサイドも絡むのならちょっと使うのをためらってしまいますね。

ブログ100ページ目は”おやじの会”のみなさまです(o^-')b !

  

”おやじの会”からお写真が届きました。

緑小学校に通う子どもたちのお父様たちがメンバーとなり、地域の方も誘い合い、毎年お餅つきをしています。

今年も200名以上が参加され、盛大にお餅つきが行われたそうです。

”おやじの会”のロゴと小学校の紋章入りの餅臼を囲んだお写真を拝見しとても嬉しく思います。

有難うございました!!

 

当社ブログ100ページ目、そして2017年最後のブログを飾っていただきますっo(^0^*)o♪

 

子どもたちの更なる成長を願って!

 

 

お父様、お母様 祖父母の皆様、ご苦労様でした。

そして 有難うございました!

 

2018年 嬉しいがたくさん訪れますように。

 

 

 

 

 

 

 

category : 近況 author : 大住 美春
tag : 

 

 

餅つき

 

2017年12月29日 今年も有難うございました<(_ _)>。

阿波銘木の大住です。

12月29日、大掃除も終わり2017年も無事に納めることが出来ました。

特に今年は、餅臼机上名札のリピート様が多く当社の商品をご愛好くださいまして誠に有難うございます<(_ _)>。

26日には今年最後の餅臼の納品でした。

雄武町こども育成会の皆様、楽しく可愛らしいお仕事をさせて頂きました。

めだかのリボンと帽子、そして泡吹くは、ちょうど同じような色合いのカッティングシートがありましたので

ロゴそのままに作成致することが出来きました。子どもたちの笑顔が目に浮かび思わず力が入りました^^。

ほんとうに有難うございました。 

22日には急きょ太い丸太が3本入り、来年用に木取りも済ませました。

2018年の仕事はじめは特大の臼削りからです。

太くてスタイル抜群の桜材に小川さんも↓すっかり惚れ込んでおりました(*^^*)。

机上名札は2018年1月18日スタートのTVドラマの美術協力を致しました。

年明けにはHP並びにこちらのブログにて紹介をさせていただきます。

来年は更に研究を重ね皆様に満足いただける商品造りに邁進してまいります。

2018年は1月9日より通常営業となります。

2017年 ほんとうに有難うございました!

 感謝!

 

 

 

 

category : 近況 author : 大住 美春

Symfony4 Release!!

東京もすっかり寒くなりました。

 

東京では僕の地元の北海道とは違って、クーラーをつけていてもジャージとかの長袖で過ごす毎日です。

ストーブのパワーに脱帽しますね。

 

お久しぶりのwebシステム担当です。

 

さて、前回のブログでSymfony3について書かせて頂きましたが、

ついにSymfony4が正式にリリースされました!!

 

当サイトも既にSymfony4へのコンバートに取り掛かっており、来年頭には4系での運用に入る予定です。

ちなみに同時期にリリースされた3.4は長期サポートになっておりますのでリスクを背負わずにSymfonyを使いたい方はまだ4系にするべきではないですね。

この辺は好みにもよると思いますが。

(追記:2017年12月26日により、当サイトはSymfony4.0.2・PHP7.2.0での運用を開始致しました。)

 

そんなSymfony4ですが2系3系と比べて非常に大きく変わった印象を受けます。

と、言うコトで下記にまとめてみます。

 

Bundleless Applicationになった↓↓

これが最も大きく変わった部分ですね。Bundlelessにするのは想定外でした。

Symfonyといえば2系からはBundleを切りながら、そのBundle内で1アプリケーションの機能を完結させるフレームワーク設計だったのですが、それがなくなりました(1系は忘れましたが似たような機能があったような)。

僕個人の感想ですが、Bundleを切ることでその中で完結できる反面、各Bundleごとに似たようなロジックを書くことも多いなという印象がありました。

もちろん共通のBundleを切るなりclassを実装するなりしてそっちを見ろよという意見もあると思いますが。

 

Controller Action Namingの変更↓↓

毎度恒例だったController内のfunctionにActionサフィックスをつける必要がなくなりました。

 

DIが使いやすい↓↓

DIとはDependency Injection(依存性注入)のコトを指します。

3.3系の時からなのですが4系も変わらずDIが圧倒的に使いやすいです。それまでずっと設定ファイルがカオスになってましたからね^^;

PHPのフレームワークではLaravelのDIが衝撃的に使いやすかったのですが、今のSymfonyも同じくらい使いやすいと思います。

詳しいコトはこちらのリファレンスを見れば分かるかと思います。

 

Annotationで設定を記述するのがBest Practices↓↓

Best PracticesではRoutingなどはAnnotationで記述したほうがいいとのことです。

従来と同じく設定ファイルにまとめる方法でも出来ますが、デフォルトの設定がAnnotationでやろうねってなっていますね。

当サイトも現在、設定ファイルから各Annotationへの記述に寄せています。

正直、yamlで設定するほうがいいんですが。。。

 

ディレクトリ構造が変わった(おまけ)↓↓

メジャーバージョンアップの際は毎度好例なのですが今回もディレクトリ構造に変更があります。

また、設定ファイルにも変更があります。

まぁ儀式のようなものなのでリファレンスを読めば問題ないですね。

 

 

サンプルロジックもGitHubに上がっていますのでそれを見たほうがしっくりくるかもしれません。

僕はサンプルロジック等は見ていません。リファレンスを見た結果、内部で使われているclass何かはほとんど同じと判断したので。

思想は大きく変わりましたが、1つ1つのclass自体はほとんど変化はないように思えます。

 

個人的には、旧バージョンより非常に使いやすくなった印象を持ちました。

 

 

 

これからバグなんかも出てきて何度かマイナーバージョンアップがあるかと思います。

Symfony4がどのように評価されるか今から楽しみです。

カテゴリー
最新記事
アーカイブ
カテゴリー
最新記事
アーカイブ
facebook
Twitter
Google+
TOPへ戻る