大規模SIerだけど、推し技術でなぐり合うLT BATTLEを企画・運営して社長表彰とりました！ - そこに仁義はあるのか(仮)
タイトルの通り、推し技術でなぐり合うLT BATTLEイベントで社長表彰をもらいました！ 下の記事でも書いた、LT FREE STYLE BATTLEです(✌'ω' ✌) syobochim.hatenablog.com 🎉 社長表彰のようす 弊社の社長表彰には「優秀プロジェクト賞」や「ベストセールス賞」、「グローバルチャレンジ賞」「生産革新賞」など、様々な賞があります。 その中の「グッジョブ賞」（よい行いをしました。）を獲得しました！(✌'ω' ✌) 社長から賞品をいただいている様子。 会場には、他の賞をとった方達と本部長、事業部長、部長がいました。 金一封（！）と盾、副賞として社長のイラストがプリントされたお米と弊社ロゴの付いたお箸、社長イラストが書かれたシールをいただきました！！（シール困る…） その後の懇親会。ケータリングうまかったな…。 🎉 おもったこと LT FREE ST
アーキ部：仕掛学（ひとを動かす仕組みをつくる） - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) 10/28のアーキ部は「仕掛学」がテーマでした！ 仕掛学？ 仕掛学は、人が自分の意思で動くような仕組みを作ること！٩( ´ω` )و 『注意喚起の張り紙をして、「なんで皆行動をなおしてくれないの？！｡ﾟ(ﾟ´ω`ﾟ)ﾟ｡」となる』のを仕掛学によって回避しよう！ 主にこの本の内容が紹介されていました！ 仕掛学―人を動かすアイデアのつくり方 作者: 松村真宏出版社/メーカー: 東洋経済新報社発売日: 2016/09/23メディア: Kindle版この商品を含むブログを見る 仕掛学のポイント 仕掛学では、3つのポイントをおさえて仕組みがつくられています！ 公平性：誰も不利益を被らない 誘引性：行動が自然に誘われる 目的の二重性：仕掛ける側と仕掛けられる側の目的が一致していない たとえば？ case1. 背表紙に斜めの線を
アーキ部：自分のエンジニアスキルを客観的にどうやって知るか - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) 9/16のアーキ部は「自分のエンジニアスキルを客観的にどうやって知るか」がテーマでした！ （アーキテクチャの話ではない？！！） 自分のエンジニアスキルの評価として陥りやすい考え方のお話があり、それに対して少人数のグループに分かれて自分はどちらに分類されるかを話あいをしました。 （この会はとりあえず意見を発散する場でした。次回は、今回の話し合いに対しての深堀りなのかな？？） 評価の分類 自己評価は（バランスがとれている人もいるとは思いますが）過大評価をしているか、過小評価をしているかに分かれると思います。 アーキ部の最初に、自己評価の考え方として陥りやすい傾向が二つ紹介されました。 詐欺師症候群 ダニング＝クルーガー効果 詐欺師症候群 参考にしたサイトから説明を抜粋しています！ 詐欺師症候群とは、自己評価が低く、自分
アーキ部：テーブル設計をやってみよう！ - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした！ この記事がすごく良かったので、触発されてブログ書く！！！ developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
受託開発でGitとmavenを使って開発をしている - そこに仁義はあるのか(仮)
会社で受託開発していて、gitを使った開発フローを考えることになった。 ニアショアに開発をお願いしていて、ニアショアからの受け入れタイミングが何回かあるから、それにあわせてブランチをわけている。 どういうフローで進めているかと、一番最後にやってみて思ったことを書いた。 どういうフローでやっているか リポジトリの構成 下記モジュールを用意した。 parent core entity common web batch tools ニアショアにて開発するモジュールは『common』、『web』、『batch』で、 アーキにて開発するモジュールは『parent』、『core』、『entity』。 ブランチ ブランチはこんな感じで分けている。 ちなみに、ソース管理はgitBucketを使った。 masterブランチ … リリース可能な状態の資源のみを管理する。結合テスト実施時は、本ブランチから資源を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
