トラストバンクのパブリテック事業でPdM兼エンジニアとして自治体向けSaaS企画開発運用。JAWS初心者支部とLWTTの運営。AWS Samurai2019。興味:AWS/Python/kintone/SaaS/Cloudflare/
2021年現在、ベイジの柱の事業はウェブ制作事業とウェブアプリデザイン事業です。ウェブ制作事業は会社設立の2010年からの主力事業で、サービス品質の平準化を目的に2014年頃からワークフローの整備を進めてきました。 一方ウェブアプリデザイン事業については、事業拡大したのがここ数年で、まだワークフローが整備されておらず、各人の裁量に委ねた進め方になっていました。そこで今後の事業拡大とメンバー増員を想定し作成したのが、業務システムやSaaSのUIデザインに特化した「ベイジの業務システムUIデザインワークフロー2021年版」です。 基本的な進め方は国際規格(ISO 9241-210※)の人間中心設計プロセスに基づいて組み立てていますが、細かいタスクの順序や内容は、今までベイジで培ってきたノウハウをふんだんに盛り込み、組み換えています。 また今回ワークフローを整備するうえでは、クライアントごとの開
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント(ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー)の作成、安全な取り扱い、
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
2019年3月にクレディセゾンに来て、ゼロからチームを立ち上げて1年半が経った。「セゾンのお月玉」を始めとして戦略的企画を自分たちで企画し、実装し、改善し、運用していくチームはとても良い感じで動けていて、現在もいくつかの大型プロジェクトに仕掛中だ。2ピザチーム(8人)ひとつでやっているにしてはかなり良い動きができていると感じている。 だが、1年経過した頃から『これは絶対に成し遂げたい』と思うことが出てきた。 1.「事業会社とSIが分かれている問題」と向き合う それは「事業会社とSIが分かれている問題」をどうにかすることだ。 新規の戦略的企画を作る私たちのチームは完全内製で開発をしている。一方、事業部門のシステムはすべて外部に委託している。 だが事業会社とSIが分かれていることで、企業対企業でやり取りをしなければならず、エンジニアリング以外のマネジメント業務が大量に発生し、開発に必要な期間や
イントロ「Amazonのこの商品をチェックした人はこの商品もチェックしています」や「YouTubeのあなたへのおすすめ」、「Twitterのおすすめユーザー」などのレコメンド機能は多くのWebサービスに組み込まれております。そのレコメンドによって、ついつい商品をたくさん買ってしまったり、夜遅くまで動画を見てしまった経験はないでしょうか。 この記事では、レコメンドシステムの裏側はどのような仕組みになっているのか、そもそもレコメンドとはどういうものなのかを具体例を交えながら俯瞰できればと思います。レコメンドシステムのアルゴリズムの詳細には触れず、ビジネスにおいてどのような形で実装されているかにフォーカスしています。ネット上に公開されているレコメンドに関するスライドや記事、論文のリンクをまとめましたので、アルゴリズムの詳細などはリンク先の記事でご確認ください。 対象の読者は、自社のサービスにレコ
最近問い合わせを捌き切れなくなってきて、対応漏れが出てきたので、Google Form, Slack, Zapier, Trelloで簡易的なヘルプデスクシステムを作ってみました。ZapierはStarter以上のプランが必要になります(多段Zapである為)。トライアルでも同じものが作れます。 社内のヘルプデスクの歴史歴史というほどのものでもなく、半年以内の出来事なのですが簡単に経緯だけ説明します。実装方法だけ知りたい人は後ろの方を見てください。 入社時(2019年2月)そもそも弊社には私が入社するまで専任の情シスはおらず、一部開発者や総務・人事などのメンバーが手分けしてPCやネットワークの不具合などを対応していました(多分) 私が入社してからは、待望の専任者ということでDMや様々なチャンネルでメンションが飛んできて判断軸もまだ定まっていなかったのでなかなかカオスな状況でした。 GASとG
これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編) こんにちは nob です。 前編 これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編) の記事から1年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を(システム編)としてお届けいたします! 今回の(システム編)で紹介するツボは 4 つです。(クエリ編)のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 (ツボ1)Load Average < (1 + (cpu数-1)/3) (ツボ2)Checkpoint Age が水平線になったら要注意 (ツボ3)MyISAM は無いよね監視 (ツボ4)万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
SEに最も必要なスキルは「伝える力」だと言われています。分業が前提となるシステム開発において、意志の伝達がうまく出来ないことは致命的だからです。 よって、作成するドキュメントにも正しく伝える技術が求められるのですが、しかし多くのSEはドキュメント作成を苦手としているようです。 そこで今日は、SEがドキュメント作成で失敗しがちなポイントと、ドキュメント力を強化するための5つの視点について、『エンジニアのための文章術再入門講座』からご紹介します。 1.SEがドキュメント作成で失敗しがちなポイント SEがドキュメント作成に失敗しがちなポイントは、主に以下の2つです。 相手の関心と不一致 知識差のための説明が不足 例えば、システム開発プロジェクトの部長向けの進捗報告の場面を思い浮かべてください。性格にもよりますが、一般に部長クラスの方が気にするのは「予算を超過しないか」「顧客との関係は良好か」「今
2012年04月19日17:03 カテゴリランキング 海外サイトが選ぶ『絶対にプレイすべき今世代のJRPG』 ブルードラゴン(360)ファイナルファンタジーで有名なクリエイター坂口博信によって設立されたミストウォーカーは、 ヒットにこそ恵まれなかったものの、いくつかの最良なJRPGを生んだ。 デモンズソウル(PS3) カルトヒットとなったソウルシリーズは、バンナムの元で更なる成長を遂げた。 確かに伝統的なJRPGではないし万人受けとも言い難いが、それは実にユニークな体験を提供してくれるはずだ。 魔界戦記ディスガイア4(PS3)もしあなたがコメディとやり込み要素を求めているならば、ディスガイアシリーズを手に取るといい。 ドラゴンクエストV 天空の花嫁(DS)戦闘システムは単純で、従来のドラクエシリーズと何も変わっていない。しかし仲間モンスターシステムと世代を超えた感動的なストーリーは、いまだ
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
Bazaarでござ~る。猿でもできる分散バージョン管理“超”入門:ユカイ、ツーカイ、カイハツ環境!(20)(1/4 ページ) 「“分散”バージョン管理は難しい」という人こそ 最近、GitやMercurialが注目を浴び、SubversionやCVSなどの中央型のバージョン管理システムに代わり分散型のバージョン管理システムの普及が進んでいます。本稿では、GitやMercurialに比べ、いま一歩マイナーな分散バージョン管理システムである「Bazaar」を紹介します。 本稿は、想定読者層としてはSubversionやCVSを、すでに使っており、分散バージョン管理システムに興味がある方を対象としています。「分散バージョン管理システムって何?」と思われる方は、連載第3回の「分散バージョン管理Git/Mercurial/Bazaar徹底比較」を参照しておくとスムーズに読み進められると思います。 なお
セッションタイトルは「ゲーム屋がソーシャル業界で成功するために 〜ダービー×ダービー安定運営までに得た教訓〜」。ゲーム屋さんがサーバー周りの構築などに苦労した話が語られています。 ビジネス&マネージメント | CEDEC 2011 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2011/program/BM/C11_P0117.html スライド資料はこちら。 実際のサーバー構成や実際の数字を交えた実践的な内容でゲームに限らず、アクセス数の多いサイトのサーバの構成方法としても参考になると思います。 ゲーム畑の方が悪戦苦闘しながらシステム構築した話が書かれているのでサーバ周りが初心者な人がどの辺りを中心に勉強して行けば良いかの参考にもなると思います。 スライドを見て参考になった箇所 ダービー×ダ
MeCab に至るまでの形態素解析器開発の歴史等はこちらをご覧ください メーリングリスト 一般ユーザ向けメーリングリスト 開発者向けメーリングリスト 新着情報 2008-02-03 MeCab 0.97 マルチスレッド環境で辞書を開くときの排他制御がうまくいっていなかったバグの修正 Windows版でインストール時に辞書の文字コードを指定できるようになった 一部のコンパイラで正しくコンパイルできなかった問題の修正 部分解析モードを変更するAPI の追加 (Tagger::set_partial()) ラティスの生成レベルを変更するAPI の追加 (Tagger::set_lattice_level()) 温度パラメータを変更するAPIの追加 (Tagger::set_theta()) 全候補出力モードを変更するAPIの追加 (Tagger::set_all_morphs()) 2007-
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く