DEV Community: Bruno Silva

Fullstack app buildalong!

Bruno Silva — Sun, 27 Aug 2023 00:13:57 +0000

Today I'm starting a new series here: let's build a full stack app together! I'm going to document all the development steps of a fully functional web app and share the decisions I make along the way, the tools I'm using and the thought process as the general idea evolves.

The goal is not to come up with something revolutionary, but to showcase every layer in a stack of programming technologies, working together. If you're a newbie it will work as a series of examples of several different pieces being weaved together for something larger. If you're an experienced developer, this may be a chance to see some of the new stuff that's coming out, or better yet, make suggestions!

Every now and then I'll post a pull request here for the community to provide feedback on.

The very basic functionality of the app is going to be: frontend layer, backend layer and relational database. The interface is going to present the user with flashcards containing helpful information and the user will have the chance to add pre-created flashcards to their collection, or build flashcards from scratch.

I've picked some technologies I'm very familiar with and others that I wanted to have an opportunity to play with. Here's the stack as of today:

Frontend: Angular (TypeScript)
Backend: .NET 8 (C#)
Database: MySQL
Hosting: Azure
CI/CD: Github Actions

The repo for the frontend code is:
https://github.com/brunosilvadev/hon

The backend can be found at:
https://github.com/brunosilvadev/hon-api

Follow along as it takes shape from the bare bones of boiler plates to a fully featured app. We'll add auth providers,tweak the pipelines, refactor the database architecture as the application evolves and listen to feedback from the users.

For the newbies in web development, I'll be happy to answer your questions and explain the logic as we progress.

On the next episode, I'll describe the initial architecture and the different bits of the boilerplate that's already in place.

Let's build it together?

A verdadeira faixa salarial como dev nos EUA (ou o andar de baixo)

Bruno Silva — Wed, 02 Aug 2023 22:15:36 +0000

Esse é um tema que mexe muito comigo. A minha intenção é esclarecer um tópico um pouco turvo, que eu vejo muito sendo mal representado ou com informações muito superficiais. O Lucas Montano fez um ótimo vídeo sobre o tema. O que eu escrevo aqui é um complemento. Recomendo assistir o vídeo dele primeiro e depois voltar aqui.

A forma como eu descrevo é a sensação de ter chegado em um monumento ou ponto turístico para admirar, mas eu cheguei pelo lado de trás e entrei pela porta dos fundos. Fiquei admirado, sim. Mas depois de um tempo eu percebi que na verdade estava vendo o lado de trás do monumento, enquanto todo mundo conhece a perspectiva principal. Muitos nem sabem que esse lado de trás existe.

Alegoria da Caverna de Platão faz sentido aqui

Calma que vai fazer sentido.

Eu e a minha esposa chegamos nos EUA em 2014, com uma mala contendo um monitor 24 polegadas e uma máquina de café espresso. Depois de um processo muito doido (que envolveu muita sorte), eu tinha recebido uma oferta para ser transferido para a matriz da empresa onde eu já trabalhava em São Paulo. Eu receberia o visto L1 e me mudaria para Kansas City, que fica bem no meio do mapa dos EUA continental.

Obviamente eu estava empolgadíssimo com a mudança. Hoje em dia existem milhares de histórias de pessoas que saíram do Brasil para trabalhar com tecnologia no exterior. Mas 10 anos atrás isso não era tão comum. Trabalho remoto, então, era coisa de ficção.

A minha história com essa empresa foi longa: depois de ter tido o green card negado uma vez, eu finalmente obtive a permissão para trabalhar, que é o documento que antecede a autorização de residência permanente. Depois de 6 anos na mesma empresa, no mesmo cargo, eu podia pensar em procurar outra oportunidade.

Literalmente no meio

Foi só nesse momento que eu comecei a me interessar em faixas salariais e quanto as empresas estavam pagando na área de tecnologia. Foi um choque muito grande quando eu conversei com uma recrutadora, que me perguntou a pretensão salarial, e eu disse um valor que deixou ela surpresa.

Esse valor é muito abaixo do mercado. Não faz nem sentido. Vamos passar a sua pretensão salarial como tanto

Um pequeno parênteses com relação aos níveis: pelo menos aqui na minha região, pouquíssimas empresas têm um cargo "Junior Engineer". Basicamente a pessoa é desenvolvedor ou desenvolvedor sênior. Mas a maioria é sênior. Nas 3 empresas onde eu trabalhei nos últimos 10 anos, a divisão do time de dev sempre foi assim: 80%+ era sênior. O restante era "pleno", embora não exista termo equivalente aqui. Nenhum Júnior. Característica aqui da região.

Bom, foi a partir da conversa com aquela recrutadora que eu fui pesquisar mais sobre faixas salariais. Como eu disse no parágrafo inicial, esse foi o momento que eu consegui dar a volta no monumento para poder vê-lo de frente. E o que vem a seguir são as conclusões que eu consegui tirar desde aquele processo até hoje.

Meu primeiro salário como dev nos EUA (2014): $60k anual.

Já era abaixo da média na época. Existe um salário mínimo para contratação do visto H1B (o da loteria, muito comum na área tech). Acredito que a empresa na época quis equiparar a oferta L1 com ofertas H1B.

Esse é um ponto importante de frisar: muitas empresas abertamente oferecem salários abaixo do mercado para profissionais que dependem do visto, exatamente porque para um funcionário assim, é muito mais difícil sair da empresa.

Meu salário depois de 5 anos atuando como dev nos EUA (2019): $84k anual.

Aqui o meu salário era criminalmente baixíssimo para o meu tempo de experiência. Eu tocava projetos sozinho, liderava um time offshore. Mas vocês sabem como empresas são para dar aumento. Foi mais ou menos nessa época que eu quis sair dessa empresa (e tive que pagar uma multa cujo valor era maior que um carro 0km, mas essa história eu conto em outro post).

Depois de ir terrivelmente mal na primeira entrevista técnica (eu não me dei ao trabalho de me preparar, porque achava que não precisava), eu fui atrás de mais informações. Foi quando encontrei vários fóruns e repositórios de informações valiosas, como o subreddit CSCareerQuestions, que frequento até hoje. Também o perfil e o blog do Gergely Orosz, que fala muito sobre mercado de trabalho em tecnologia Europa-EUA. Conheci o levels.fyi, o Blind e o leetcode. Não vou me aprofundar muito nessas referências, mas é muito fácil de achar uma tonelada de informação sobre eleas.

Meu "salário total" como Senior Engineer na segunda empresa: ~$150k anual.

Eu uso o termo "salário total" (ou total compensation) para incluir o salário, ações e bônus anuais no mesmo pacote.

Fiz um comentário uma vez nesse subreddit, fazendo menção ao valor do meu salário. A resposta que eu recebi está na minha barra de favoritos do navegador até hoje: "150 mil para um dev sênior me parece meio baixo, mesmo numa cidade com baixo custo de vida". Então eu mostrei para a pessoa links com a página da minha cidade no levels.fyi, algumas vagas de LinkedIn, apenas constatando que esses 150k são na verdade bem acima da média aqui onde eu moro.

Acontece que as pessoas que sempre trabalharam nas big tech ou nos hubs de tecnologia, tipo Vale do Silício, nem sabem disso. Nesses casos, a remuneração nunca é apenas em dinheiro: normalmente as empresas oferecem um salário em cash, adicionado de uma parte em ações da empresa e talvez mais um bônus anual.

Na mesma época eu salvei também este tweet do grande Hugo Marques, em que ele basicamente diz "menos de 200k é salário de Junior. Pleno ou Sênior chega a 250k-350k fácil". A palavra "fácil" nessa frase me causa mal estar até hoje.

Depois da onda de layoffs e do mercado ter ficado mais morno, eu finalmente voltei a receber mensagens de recrutadores pelo LinkedIn. Semana passada me convidaram para candidatar a uma vaga de tech lead em uma rede de cinemas (cuja sede fica aqui em Kansas City). O salário: $120k anual, sem bônus. Só.

Essa é a realidade da maior parte das pessoas que trabalham com desenvolvimento nos EUA. Quantas empresas podem pagar um salário acima de $200k anual para um programador só? Fora as grandes como Netflix, Meta, Uber, Apple, Google etc, será que mais umas 100 empresas, talvez um pouco mais? As faculdades e bootcamps estão formando milhares de pessoas todo ano e essas pessoas estão indo parar nas empresas de seguros, nos bancos, na logística, no varejo, na indústria. Todo mundo precisa de um app e quase toda empresa a partir de certo tamanho precisa de um departamento interno de desenvolvimento, nem que seja para manter os sistemas internos.

Meu salário total, agora como tech lead numa empresa pequena de tecnologia: ~$165k anual.

Eu não tenho ações nem nenhum tipo de equity como parte do salário. Nunca vi uma empresa local oferecer isso. Com a onda forte de retorno ao presencial, tem sido cada vez mais difícil encontrar empresas de tecnologia (dentro daquelas 100 ou mais) que oferecem vagas remotas. E se você me perguntar, eu já contemplei sim a possibilidade de me realocar para outra região em busca de salários maiores. Mas essa é uma questão muito maior e mais complexa do que apenas o salário das vagas, então vou deixar para outro momento.

Foi urgente, para mim, escrever esse artigo, porque eu sinto que esse “andar de baixo” das vagas de TI nos EUA é muito mal representado, e muitas vezes completamente ignorado. Assim como na thread do Reddit que eu contei meu salário e disse que era comum na minha região, alguém respondeu “cara, isso é terrível”, pelo menos agora eu tenho uma noção muito melhor do abismo que existe entre as faixas salariais daqui e as do “andar de cima”. E eu vou continuar buscando o elevador ou escada que vai me levar ao piso superior.

Não é do meu costume escrever posts em português, essa foi uma exceção. Me siga no LinkedIn para acompanhar os conteúdos que eu posto lá. Abraço!

Turn your Chromebook into a .Net developer machine!

Bruno Silva — Sun, 23 Jul 2023 23:34:07 +0000

If you'd like to skip the intro and head straight to the step by step, click here.

Did you know Chromebooks are present in more than half schools in the US? I'm not making that up: according to CNBC, the lightweight laptops have overtaken Apple and Windows based computers. Source

But what's a Chromebook anyway? It's a generally modest laptop that runs ChromeOS, a Linux based operating system that bases itself on the Google Chrome browser. Most applications run on the browser and the UI is very similar to Chrome itself.

Modest, you say? So could it possibly be used as a developer machine? The answer is yes! We're going to cover here the steps in order to setup a dev environment and start coding with a simple Chromebook!

But why would one do that, you ask. There are many reasons: maybe you've wanted to start studying software development but has been putting it off because you don't have a good computer. Maybe you have a friend or family member who wants to learn how to code but they don't have access to the latest tech. And maybe you have a Chromebook laying around anyway.

As a #dotnet developer, obviously I'm going to focus on setting up a C# development environment. But wait a minute, isn't dotnet a Windows-only endeavor??? No! And it hasn't been for quite a while. The .NET ecosystem is free, cross platform and open source. For the last decade it's been possible to build .NET apps using C# on Mac and Linux, not just on Windows.

And I'm not even getting into the job opportunities for C# developers. In a market saturated with JavaScript aspirers, there's a world of .Net systems that will continue to need developers for the foreseeable future. As usual, one of my target audiences for my articles here is the older C# developers who have been through the .Net Framework 3.5 days and may not be aware of all the new things the ecosystem has to offer these days. So come along and let's get set up!

Setup

The first thing you'll need is to enable Linux in your ChromeOS. This is a really nice feature that's available to most Chromebooks made these days. go to Settings, expand the “Advanced” menu and go to “Developers”. Then click “Turn on” to enable Linux. More details here: https://chromeos.dev/en/linux/setup

It'll give you access to the Linux terminal. If you've worked in a Linux based environment before, you'll feel right at home. My favorite code editor is VSCode, so let's hop over to this page and download the deb version. ChromeOS's Linux subsystem is based on the Debian system.

After it's installed, either click the icon or just type code in the terminal. We're almost there! Next, I'm going to install the dotnet runtime. This is necessary in order to run our C# applications. On this page there's all the steps, but basically we'll need to add the Microsoft package source for apt-get and run a sudo apt-get install.

It should be as simple as running this command:

wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb

and then this command:

sudo apt-get update && \
  sudo apt-get install -y dotnet-sdk-7.0

If everything is working fine, you should be able to run dotnet new and create your first application on the Chromebook! It's really that simple. If you're new to the dotnet CLI, head over to my other article. I focused on older C# developers who have relied on Visual Studio and Windows for years (which was my case a few years ago) but it will be helpful for newcomers as well.

As always, follow me here or on LinkedIn for more tips. And let's build cool stuff!

Step by step: How to host your dotnet projects on Azure for free

Bruno Silva — Fri, 09 Dec 2022 22:55:30 +0000

Have you started working on side projects to improve your skills and explore new technologies? Fantastic! But how to host your web apps so that you can show them to other people? Luckily there's a free tier in the Microsoft cloud service Azure that lets you do just that: host small scale apps for development and study purposes.

Don't think it's important? I was interviewing for an engineering position at a Startup last month and had the opportunity to mention my Croupier API, which basically serves cards from a common playing deck. The interviewer was impressed that I could tell him the URL to open so he could play with it.

Cool, huh? It's not that complicated. Follow along and we'll do it together.

> Disclaimer that needs to be made: I am giving these tips so that you can find the way to do it. If the configuration is not done correctly there is a chance you may get charged for services. Always double check with Microsoft’s support to make sure you’re using the free services and only that. Your mileage may vary but I was asked to provide a phone number and credit card number for identification.

To make it even more fun, I’ll do it from a Mac computer (so no Visual Studio available) to show you that it can be done on any kind of device. Dotnet really is multi-platform. So we begin typing in the following command in the terminal (that’s assuming you already have dotnet installed):

dotnet new webapp -n Sidegig

Here’s the terminal output.

I chose Sidegig as a catchy name but feel free to choose a name for your project. I’m going WebApp but you can do MVC, WebAPI, anything that will have an HTTP interface and can be accessed via web browser. To see what it looks like just open the terminal inside the Sidegig folder and run

dotnet run

Not too shabby, huh?

Now we’re going to hop on to Github. I’m hoping you already have a Github account but feel free to create one if you don’t. I’m going to click “Create a new repository”. This is what the screen is going to look like:

I’m naming the repo sidegig-app, but really anything works here.

Then I’m going to clone that repo to my computer. I’m using the command git clone but you can use the Github CLI or a GUI git program for that.

After copying the files I’ll open the folder in VSCode to check in the changes.

Browsing the repository at Github.com to make sure that everything is there and looking good.

Now on to the hairy part. Go to portal.azure.com and log in with your Microsoft account.

I created a new Microsoft account just for the purpose of this tutorial, so your experience should be similar to mine. You’ll search for the Free Trial option. It’ll take you to a separate webpage outside of the azure.com domain. I was asked to provide a phone number and credit card number for identification purposes. They tried to sell me a premium support service, which I declined.

> Again, always make sure to choose the Free Trial, Free Tier option. In case of doubt, reach out to Microsoft support. I am not responsible if you accidentally sign up for a paid service.

After that was completed, I was taken back to the Azure portal with some commonly used features highlighted. Go ahead and click Create inside the Azure Web Apps block.

The next projects you post to Azure are going to be very similar from this point on. The next thing we need to do is create a Resource Group. These are like entities that group the services you get into chunks of consumption for billing purposes. I’m going to name it sidegig-app-resource-group for simplicity.

Then you get to choose the URL. I’m going with sidegig.azurewebsites.net.

Choose to Publish your Code (first option). Runtime stack is the dotnet version you’re going to use. You need to choose Windows for the free tier.

Now comes the most important part: open the Pricing Plan and choose the Dev/Test tab. From there choose F1, the one that says Free. The computing is far more than enough for this exercise.

Next step is the most fun of all. Switch the Github Actions setting to Enabled and link your Github account. You’ll see that it shows your profile as an organization. From there choose your repository and branch. I’m picking the repo sidegig-app. You’re now ready to click Review + create.

It’ll take a moment to download your code from Github, build and publish it.

After it’s completed, click at Go to Resource and, from there, click Browse. Or simply navigate to the URL you had chosen previously to see your app there, running on the cloud. And for free.

Pat yourself on the back. Your little project is out there for the world to see.

Also make sure to go back to your repo at Github and click the Actions tab, to see some of the stuff that happened behind the scenes.

Now the magic is all set up. Any change you make and publish to the main branch will trigger this Github Action, which in turn will update your app on Azure. All automated, instantly and for free!

Thanks for the read! If you’ve liked this step-by-step guide, make sure to give me a follow here or at my LinkedIn. Hope you have a great day!

Minimal API endpoints getting messy? Let's get organized

Bruno Silva — Fri, 11 Nov 2022 20:08:20 +0000

I was a loud advocate and early adopter of dotnet's Minimal API framework for managing endpoints. It solves the problem of Controllers being verbose and cluttered, heavily geared for the MVC architecture and frequently being responsible for returning a fully rendered view from the backend. While also provides a much more flexible structure for your Rest methods. If you don't know what I'm talking about, make sure to check my other article, which should help you switch from dotnet controllers to endpoints.

We went from this:

using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using sandboxing.Models;

namespace sandboxing.Controllers
{
    public class HomeController : Controller
    {
        private readonly ILogger<HomeController> _logger;

        public HomeController(ILogger<HomeController> logger)
        {
            _logger = logger;
        }

        public IActionResult Index()
        {
            return View();
        }

        public IActionResult Privacy()
        {
            return View();
        }

        [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
        public IActionResult Error()
        {
            return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
        }
    }
}

To this:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Now, I've been hearing people complain that it gets cluttered and messy once you start having more than a few routes to specify. You don't want to be touching your Program.cs all the time and nobody wants to clutter a critical file with 100 lines that look more or less the same. I personally know the pain, as one of the microservices in the app we're building at my job has over 100 endpoints. It's easy to get lost, but there's ways to work around the mess.

Here's the solution we came up with: create an interface, separate each logical domain into a different file with its own routes and each of these files implements the interface. Then during the application startup, we iterate through every single implementation to get the routes registered.

Sounds tricky? Check this example and you'll see it's pretty straightforward.

First, the interface with the RegisterRoutes signature, that receives an IEndpointRouteBuilder

public interface IEndpoint
{
    void RegisterRoutes(IEndpointRouteBuilder app);
}

If you had separate controllers in the past, now you should have separate endpoints with a group of routes. The implementation will be much closer to the bare bones of Minimal APIs than with old school MVC Controllers.

This is a part of DeckEndpoint, one of the endpoints in my playing cards API Croupier (check it on my Github)

public class DeckEndpoint : IEndpoint    
{
    public void RegisterRoutes(IEndpointRouteBuilder app)
    {
        app.MapGet("/new-game", NewSession);
        app.MapGet("/draw-card", DrawCard);
        app.MapGet("/see-deck", SeeDeck);
        app.MapGet("/shuffle-deck", ShuffleDeck);
    }
}

The second parameter in the MapGet method is a delegate. NewSession, DrawCard, SeeDeck and ShuffleDeck are the methods in that endpoint class.

Okay, now we just need to make sure every single instance of RegisterRoutes function is being called during the program startup. For that you'll need to add a line for each new endpoint in your dependency inversion definition, like this:

services.AddTransient<IEndpoint, DeckEndpoint>();
services.AddTransient<IEndpoint, TestEndpoint>();

You can also achieve the same result using Reflection! But it's a little more tricky so I'll save that for another time.

Now that our endpoints are registered, we just need to iterate through the implementations of IEndpoint from the DI provider and make sure the RegisterRoutes method is called:

var app = builder.Build();

var endpoints = app.Services.GetServices<IEndpoint>().ToList();

endpoints.ForEach(e => e.RegisterRoutes(app));

And we're done! Functionality-wise, every route from multiple endpoints is registered as if they were all listed in Program.cs. For reference, this is what my Program class looks like in the Croupier API:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDIServices();

var app = builder.Build();

app.UseOpenApi();
app.UseEndpoints();
app.Run();

Slim!

I hope this helps you decide to let go of old Controller ways and embrace the new dotnet features. Drop a question if you feel like so, check out the Croupier API on my Github and make sure to follow me here and on my LinkedIn. Thanks and have a good one.

Still writing Controllers in dotNet? Give Minimal APIs a try!

Bruno Silva — Mon, 19 Sep 2022 17:13:00 +0000

If you’ve been working with .NET development for a while, you’re probably used to a lot of the quirks and idiosyncrasies from the beginning of the framework time, especially before the big transition to .NET Core. Verbose would be an understatement for the traditional Web APIs and IIS-ready apps. Wow! Remember when you needed a full-fledged Windows Server system to run your dotNet apps? Thankfully the ecosystem has evolved gigantically since then.

So your typical C# web API with Program.cs, Startup.cs and a plethora of Controllers inheriting from ControllerBase there used to be lots of naming conventions and rigid structure. Code used to look more or less like this:

using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using sandboxing.Models;

namespace sandboxing.Controllers
{
    public class HomeController : Controller
    {
        private readonly ILogger<HomeController> _logger;

        public HomeController(ILogger<HomeController> logger)
        {
            _logger = logger;
        }

        public IActionResult Index()
        {
            return View();
        }

        public IActionResult Privacy()
        {
            return View();
        }

        [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
        public IActionResult Error()
        {
            return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
        }
    }
}

Fun fact: you can type dotnet new mvc to build a MVC style web app, if that’s still your thing. The code above is the HomeController you get from this command. You can modify your Index.cshtml to contain only a string “Hello World, I guess?” and send it back to the browser via the controller Index() method. When you browse to that route, the app loads the string from the controller (plus a header and footer that I really didn’t ask for).

Pretty simple, right? Well, what if could be actually simple?

With dotNet 6, Microsoft introduced the Minimal APIs paradigm, which greatly simplifies this structure and brings the C# development closer to the trendy technologies like NodeJS and Express (apparently, we’re okay with running Javascript on the backend these days).

Part of that effort has been the complete elimination of Startup.cs, which simplifies the basic boilerplate structure of Web APIs. Go ahead and type dotnet new web.

This is what your Program.cs is going to look like:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

That’s it. Four lines in a single file. The app.MapGet line assigns the anonymous function “string() { return “Hello World!”; }” to the “/” route. You browse to that route; you get the return from the function. All running from a terminal application (IIS who?) that you can easily host on your server, on the cloud, on linux or Windows, wherever.

As you can see, the verbose days of dotnet apps are past. If you haven’t given C# a try in a while, this is the best time ever to get onboard and build lean apps that perform well and can be installed on any hardware. Check Microsoft's official documentation to learn more (I swear their doc is pretty good). Long live Minimal APIs!

Using EFCore's InMemoryDatabase as an automated testing tool

Bruno Silva — Fri, 19 Aug 2022 18:27:00 +0000

Hello #dotnet friends!

We've all been there: you have your data access layer, your API handles all CRUD operations and your unit tests use mocks to simulate the interactions between each object. That's the moment you ask yourself: am I really testing anything? Since every object interacts with a mocked, simplified version of its dependencies, we're only validating the very basic functionality of the data manipulation classes.

Implementing integration tests would solve that, right? The issue is that it's not always feasible to touch the database for manipulation. What if you have a mass delete operation or something that will cause all kinds of trouble if you have to run it in production? Your test engine probably won't (and it really shouldn't) have production database access. For that scenario there's a tool that finds a middle ground between the convenience of automation with a safe, flexible and closer-to-real-data approach of a full integration test, which is to virtualize the DB. If you already use EntityFramework Core the whole process can be quite simple!

Let's say you have a database context that looks like this:

public partial class SampleContext : DbContext
{
  public SampleContext(DbContextOptions<SampleContext> options)
  : base(options) {  }

  public virtual DbSet<Product> Product { get; set; }
}

Then you probably inject that database context into your services DI provider. It will look something like this:

services.AddDbContext<SampleContext>(options =>options.UseSqlServer(
    configuration.GetConnectionString("MyConnectionString")));

This is all very typical code for EFCore and .NETCore web APIs. If you have something similar, you're in luck! I normally prefer xUnit but if you use NUnit or any other testing framework, it should look more or less the same. In your startup phase or constructor you can simply instance the DatabaseContext object in a virtualized way:

public class SampleTests
{
    private readonly SampleContext _virtualContext;    
    public SampleTests()
    {  
        _virtualContext = new SampleContext(
            new DbContextOptionsBuilder<SampleContext>()
               .UseInMemoryDatabase(databaseName: "SampleDb")
               .Options
            );
    }
}

And it's pretty much it! Now you can add data relevant to your tests and let your test methods go to town, delete, truncate, explode the database that everything will be gone once the execution is complete. Here's a basic data initializer function for the example above (using the same _virtualcontext and the Product record:

List<Product> products = new()
{
    new Product()
    {
        ProductName = "TestProduct"
    },
    new Product()
    {
        ProductName = "AnotherTestProduct"
    }
};
products.ForEach(p => _virtualContext.Products.Add(p));
_virtualContext.SaveChanges();

Now you can write tests that call the Controllers/Endpoints and validate the outputs, along with the data manipulations. Once the test manager starts up the API, it'll instance the virtualized DB and the underlying code will be agnostic to it. Nothing quite like fooling your own code, right?

Let me know if it's been helpful and follow me on LinkedIn. Thanks for the read!

Mentoria dotnet + angular para pessoas periféricas

Bruno Silva — Fri, 12 Aug 2022 14:54:03 +0000

Eu cresci na periferia de São Paulo, estudei a vida toda em escola pública e trabalhar com TI possibilitou que eu alavancasse o meu potencial e tivesse a oportunidade de oferecer para a minha família um padrão de vida que eu jamais sonhei.

Por isso eu estive pensando em alguma forma de retribuir e passar adiante essa oportunidade. A minha ideia é liderar um pequeno projeto de desenvolvimento de software, com um time que seria composto de um ou dois programadores iniciantes. É a primeira vez que eu faço isso, então seria algo bem piloto mesmo. A minha estimativa inicial é de algumas semanas, mas não tenho certeza com relação ao prazo.

Para esse fim, o processo de desenvolvimento será mais importante do que o resultado. Por esse motivo, a stack foi definida como aquela em que eu tenho mais experiência e, portanto, posso ensinar melhor. Existem muitas linguagens e tecnologias por aí, mas eu sugiro ao principiante começar focando em apenas uma.

Eu nunca ofereci esse tipo de mentoria. No meu trabalho atual não tem nenhum desenvolvedor Jr e eu sinto falta de compartilhar e tirar dúvidas. Ao mesmo tempo, para quem está iniciando nessa carreira, poder demonstrar que já trabalhou num projeto em equipe, com scrum, com versionamento, com entrega. São habilidades que podem fazer o seu currículo mais atrativo enquanto você busca a primeira oportunidade como desenvolvedor.

Exatamente por isso eu digo que o processo será mais importante do que o resultado. No fim do processo, todos nós (incluindo eu) teremos capacidades novas para incluir no currículo e oferecer ao mercado. O maior objetivo desta iniciativa é de fomentar e exercitar as seguintes habilidades:

• Colaboração em desenvolvimento
• Compreensão de requisitos
• Code review e solução de conflitos
• Saber pesquisar, saber perguntar
• Entender escopo de tarefas e qualidade de entrega

A stack:
Front end Angular. Back end dotnet 6. Banco de dados MS-SQL
Como dito anteriormente, eu até já mexi com outras linguagens e frameworks, mas essa combinação é a que eu tenho mais anos de experiência.

Requisitos:
• Ter pouca ou nenhuma experiência profissional como desenvolvedor(a) (o foco é criar um produto que você vai poder colocar no seu currículo)
• Que tenha algum conhecimento de lógica de programação, banco de dados relacional, de preferência que já tenha feito algum projeto simples como calculadora, álbum de fotos, consumir API de previsão do tempo etc.
• Tenha um computador (Windows, Linux ou Mac, tanto faz)
• Algumas horas por semana. Eu mesmo tenho bem pouco tempo livre, não vou exigir de ninguém muitas horas de dedicação, até porque a pessoa iniciante já tem muita coisa para estudar

Software, que se você já tiver instalado é um adianto:
• Microsoft Teams
• Visual Studio Code
• Azure Data Studio
• Github Desktop
• Node js
• Trello

Como vai funcionar:
Primeiro eu vou conversar com as pessoas para gente se apresentar, alinhar as expectativas e tirar dúvidas iniciais. Quando o time estiver fechado eu vou definir qual será o escopo do projeto e vamos analisar juntos as features que precisam ser implementadas e quebrar essas implementações em tarefas. Todos nós vamos organizar as tarefas da forma que fizer mais sentido e atuar nelas. A ideia é que a gente possa tirar dúvidas uns dos outros. Conforme formos progredindo, vamos incluir testes automatizados, continuous integration, responsividade, para dar mais polimento e maturidade para a aplicação.

A comunicação será feita quase exclusivamente pelo Teams. Reuniões que eventualmente forem realizadas por áudio e vídeo serão por lá também. Estou pensando num formato para uma daily stand up assíncrona. Ou seja, haveria atualização de status frequente, mas sem que necessariamente os participantes tenham que se reunir no mesmo horário.

Voltando a enfatizar que o objetivo dessa mentoria não é o produto final, mas sim a oportunidade de adquirir uma experiência que se aproxima do dia a dia em um time de desenvolvimento de software. Reforçando também que eu não sou nenhum guru, coach ou referência de mercado nem da comunidade. Eu só tenho alguns anos de experiência.

Se você acha que seria legal e acha que se enquadra, manda um e-mail contando o que representaria para você trabalhar com TI. O endereço é bruno@brunosilva.cc

Don’t sleep on dotnet command line!

Bruno Silva — Wed, 20 Jul 2022 18:44:58 +0000

If, like me, you’ve been developing Web APIs in .NET since the days of version 3.5 (or 2, or even 1.1!), then you’ve probably ran into the scenario of having to run multiple instances of Visual Studio to debug a multi-tiered or distributed application. If you’re still doing it to this day, there’s a trick to make life easier on us and on our poor laptops memory: run .NET Core apps from the terminal, even Web APIs!

Open a new terminal and browse to the project folder. From there, just do:

> dotnet run

Yes, simple like that. It triggers a build if the binaries are not present and starts up the application at the preconfigured endpoints. And if you're building .NET apps in Linux or Mac OS (you know you can do that, right?), it works just as well in the Unix terminal.

Bonus tip: If you haven’t tried the new Windows Terminal with tabs and customizable themes, check it out from Microsoft’s official Github page or from the Windows Store. It supports Windows Command Prompt, PowerShell, WSL, Azure and Visual Studio command line APIs.

It’s great to have multiple projects running locally while you work on an issue in one of the application layers. And great for not having to startup the entire Visual Studio suite several times.

What was the highest number of Visual Studio instances you had running on your machine at the same time?

Quick list of small project ideas

Bruno Silva — Mon, 11 Apr 2022 21:24:48 +0000

This is a small compilation of ideas for simple apps one can build in order to enhance their skills and practice. It's mostly targeted for beginners. Suggestions welcome. Credits to @EngineerRabbit on Twitter, she published this list originally.

Games
Tic tac toe
Snake
Scrabble or some other word game
Matching Pairs
Simon Says
Trivia
Virtual Pet/Idle game
Scavenging hunt (it can be static or you can implement an interface for the user to build their own)
Static
Picture album
Job/internship board
Fancy interactive resumé
Product catalog
Language learning portal
List of travel destinations
A simple wiki for a topic you enjoy
Management
Simple task manager
Calorie count
Exercise or habit tracker
URL shortener
Donation/free stuff board
Embeds and APIs
Advice from api.adviceslip.com
Chuck Norris (because why not) api.chucknorris.io
Dogs docs.thedogapi.com
Spotify charts developer.spotify.com
Magic the Gathering database (research APIs available)