"バックエンド"投稿一覧

Shoichi Namba

エンジニア

インフラエンジニアとのことですがhtmlの話でしょうか？
htmlに関しては絶対パスが望ましいと思います。相対パスはしょっちゅうミスが起こります。表示側だと実際に表示してみるまで気づけないのも怖いところですので。

そうではなくインフラ内部ということであれば環境によって配置箇所が違う場合もありますので絶対パスだと良くないパターンのほうが多いかもしれませんのでそこはちゃ... 続きを見る

北山 淳也

エンジニア

横江さんも書いているように Heroku や render で標準搭載されているのが PostgreSQL だからというのは理由として少なくないのではないでしょうか。

また、MySQL と PostgreSQL には互換性が一定ありますのでどっちかを選んだから大きな後悔をする、ということは全くないはずということにも同意見です。やろうと思えば後から変えることも十分に可能な範囲と... 続きを見る

北山 淳也

エンジニア

世界中にUnityエンジニアはすごい数がおり、Unityエンジンを使った開発物は今もたくさん存在しますから、
あの料金プラン変更の影響だけを受けて急激にUnityの利用が減少することはありません。

その一方でUnityが選択され始めて随分経過していますから
今後も10年20年とUnityが使われ続ける保証もありませんが、
それは去年や一昨年時点で... 続きを見る

北山 淳也

エンジニア

PHP 6 は当初、内部エンジンで扱うエンコードをすべてUTF-16に変更するという意思決定が実施され
実際に開発も進行しましたが、2010年頃にそのプロジェクトは失敗になりPHP6は欠番とすることが決定されました。
その後、内部エンジンをZend Engine 3に切り替えたPHP7がリリースされました。

バージョン番号を+1ずつ進めなければならないとい... 続きを見る

北山 淳也

エンジニア

まず Ruby にしろ Ruby on Rails にしろは現在もメンテナンスとバージョンアップがある言語/フレームワークですから
「古い言語」というのは間違った認識ではないでしょうか。

その上で、Ruby on Rails が初期のリリースからかなり経過しているフレームワークというのもまた事実です。
「受領案件の中でもRuby案件が多々あり」とのことです... 続きを見る

Koki Fujisawa

エンジニア

アピールのためのGithubなら、
【作ったものがどのように動作するか、ビジュアルで用意する。】
はけっこう大事かなと思います!

採用に携わっている方は自分の作ったものについて何も知らないわけなので言葉だけで説明されてもなかなかピンとこないと思います。相手の時間も有限ですから、理解に時間がかかると離脱されかねないというのは有り得る話かなと!
続きを見る

横江 亮佑

エンジニア

どのようなプログラムを書くかは、自身のモチベーションが一番なので、
言語などこだわらずに、書きたいと思ったものを書く方針でいいと思います。

GitHub のプロフィールページには、自己紹介を書くことが出来たり、
リポジトリや Gist をピン留めすることが出来ます。
続きを見る

Daisuke Kobayashi

エンジニア

プロダクトバックログに記載する受け入れ基準(AC)と完成の定義(DoD)をチームと見直して合意するのはいかがでしょうか？
スプリントレビュー前に品質の問題に気づいてほしい，という風に見受けられるため後者が特に重要と感じました．

Ryuzeeさんのブログでプロダクトバックログに書くACとDoDについて述べられています．
続きを見る

Dai Fujihara

プロジェクトマネジメント

MVPの考え方は、従来型のタスク分割とくらべて理解されにくいものです。アジャイル開発のトレーニングをやるときでも、MVPの考え方はかなり念入りに説明しています。

今回はデメリットということなので、自分なりに考えてみました。

まず、よくあるトラブルなのですが、初期開発の場合など、ある程度機能が揃っていなければ「ならない」開発の場合、MVPが通用しない場合が... 続きを見る

Dai Fujihara

プロジェクトマネジメント

こんにちは。アジャイルコーチとして質問のような悩みを持つ現場を支援しています。

ベロシティの数値は、スプリントプランニングで見積もった計画の数値が元になります。たとえば、計画時に100と見積もったものが90だといまいちだし、110だとよくできた！という感じです。

安定しないということは、計画がうまくいかなかったとも言えます。よって、以下の対策をふりかえり... 続きを見る

横江 亮佑

エンジニア

PostgreSQLが多いということもなく、
MySQLもよく使われているイメージがありますね。

ただ、 Heroku ( https://jp.heroku.com ) や render ( ... 続きを見る

Shoichi Namba

エンジニア

インフラやサーバーレスサービスがどれだけ発達しようとも、サーバー側の処理を書くことはどのみち必要になるのでなく今のところなることはないのではないかと思います。
どうやったってDB、API、サービスの利用を組み合わせるのはそれらを理解して書ける人でないといけません。

Taketo Yoshida

エンジニア

エンジニアの数が少ない会社では今後一人のエンジニアがまるっと担当する場合が増えると思われます。
一方で大規模なテック企業はコスト効果を考えると自社でインフラを構える事は珍しくないと思うので、まだまだお仕事は残るでしょう。

嶋田印刷

デザイナー

昔もサーバーサイドとインフラの境というか、職域は曖昧でした。
1998年のPCメーカーではPerlでCGIプログラミングをして、Webデザインもして、
ApacheWebServerで設定もしてというIT派遣案件もありました。

当時はLinuxもありましたが、Unixサーバー持ちのみが多かったです。
しかし管理者が非専門家の営業な社員で、作業の多... 続きを見る

森健太郎

エンジニア

元々クラウドインフラ系のエンジニアからDevOps などのバックエンド系エンジニアになった者です。

確かにサーバーサイドとインフラの境界線は曖昧になっているように感じています。最近はAzure のOpenAI Service などクラウドサービス上でフロントUI を持つアプリを簡単にデプロイできるものも出てきているのでフロントエンド・バックエンド・インフラという境目はこれから... 続きを見る

Nobufumi Fukumoto

プロジェクトマネジメント

PMPをとってください。そうすれば、何が必要なのかが体系的に理解できます。
IPA資格は無駄です。日本で通用するかもしれませんが、グローバルで無理ですしPMのレベルも低いです。

Waterfallが完全にできないのであれば、アジャイルだろうがスクラムだろうができません。
理由は、アジャイルもスクラムもWaterfallから早くサイクルを回すために簡略化した... 続きを見る

kentaro haneda（jumbo）

エンジニア

無くていいと思います。
ただ無いことを自覚・理解してチームやプロジェクトとして技術的な課題や進行を誰とどうするめるかをちゃんと言語化・明文化するのが大事だと思います。
ケースによって職責や作業の線引きが難しくなるので、どこまで誰が何をするか、指示なのか・要求なのかなど曖昧な部分をとにかく無くしたり、技術面以外でどうすれば工期を短縮したり・リスクと向き合えるかなどを考えてみると良... 続きを見る

ぽむ

エンジニア

ソフトウェア開発の本ではありませんが、「七つの習慣」は私のスキルの基礎となっている書籍です。
あとはカーネギーの「人を動かす」も勉強になることが多かったです。
エンジニアとしてやリーダーとしてどう立ち振る舞っていくかが学べる書籍だと思います。

Offers(オファーズ) 公式

※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント（https://offers.connpass.com/event/287192/<... 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント（https://offers.connpass.com/event/287192/<... 続きを見る