Daniel Santiago

On my journey to continue growing my crafting skills and following the guidance of my mentor Pedro Santos, yesterday we practiced the Mars Rover kata. This time, the exercise took us to the future, thinking about how to prepare the Rover for future requirements. It was an amazing exercise that made me think about making Rover open to new features (OCP) while avoiding over-engineering. My previous design was not OCP-complaint, so I made a parallel change refactoring always staying at green as much as possible, step by step. I put into practice State, Command, and Decorator patterns. I added the grid concept to control the boundaries but I still need to implement the obstacles. If you are curious about the final solution, you can check out my Github repository https://lnkd.in/gjQ4mCmS. I used Kotlin for this Kata.

27

1 comentário

🚀 Exciting News for New Developers! 🚀 I'm very happy to share my new GitHub repository: https://lnkd.in/dMiwj-t2 This project is designed to help new developers understand data algorithms through a functional programming approach using Elixir. 🌟 To kick things off, I've implemented the classic Bubble Sort algorithm. This is a great starting point for anyone looking to grasp the fundamentals of sorting algorithms while learning Elixir's functional style. Feel free to check it out, contribute, and let me know your thoughts! Happy coding! 💻✨ #Elixir #DataStructures #Algorithms #OpenSource #Programming

43

1 comentário

Hi, there! Today I concluded a #react project called "CEP Finder". This project consumes an API from ViaCep Webservice CEP to display the CEP address entered by the user. This API can find any CEP in Brazilian territory. I'm not sure if it's the same thing, but I had done a research and I discovered that in the USA there is a similar system. There, they call it Zip Code instead of CEP.   Anyway, I've known that many Brazlian programming students have done projects using this idea, that is, the idea of consuming this specifc API or a seemed one, but I implemented my own design and features. Please, check out my CEP Finder project and my other authorial projects too by clicking on the links below. Thank you for reading this post so far. I wish you a happy day wherever you are! CEP Finder: https://lnkd.in/duywTMXi My other authorial porjects: https://lnkd.in/d45BsxkN

21

8 comentários

Finish the Guess-Who Scrap CLI project written in Golang. Now, I can download and extract data on famous Brazilian people from Wikipedia, including specific states and cities. The data is saved in either Postgres or an in-memory SQLite database. In this project, I used Go as the programming language, GORM as the ORM, Cobra for the CLI, and Viper for the properties file. You can see more at https://lnkd.in/dvtTPi8R. Now, the next step is to work on the API project (https://lnkd.in/dUFwuXS8), using Quarkus, Langchain4J, Instruct Labs, etc to get the clues based on the data collected before, by the scrap project.

4

Five years ago, we started MuukTest with a question: Could we make "Great Software Testing and Automation" easier? My cofounder Renan Ugalde & I each have 20 years of Software Development & QA experience. We've seen Bad Software Testing and Great Software Testing - way too much of the former, not enough of the latter: Bad Software Testing:  - Nonexistent professional testing team, expecting "developers to do all their own testing" (which 'works' until it doesn't) - Wild, non-disciplined, exploratory testing that doesn't help  - Testing that's treated as a second-class citizen in an engineering org, not as a partner - Reactive, under-resourced testing teams  - Testing with deficient coverage and no automation at all - Testing that's treated as the last step in an assembly line - Massive teams of testers, treated like a boiler room - Testing that slows engineering down I spent years of my life in Software QA and Testing roles like this… where I spent my Christmas holidays frantically, manually running regression tests across an entire application that *had* to be released yesterday. This is bad Software Testing. It is stressful for everyone and doesn't lead to good outcomes. Great Software Testing is:  - Proactive - A mix of (smart, disciplined, strategic) manual exploration and automation - Partner to engineering - Happens throughout the engineering cycle - Performed and coordinated by small teams of testing experts  - Employs amazing tools - Helps engineering move faster - Delivers insights, not more work Since 5 years ago, we have always believed that 'Great, Fast, Efficient Software Testing' will be made possible by AI. Bad testing happens because of bad ideas and bad tools, but with AI helping with a lot of the heavy lifting of test automation and maintenance, 'Great, Fast, Efficient Software Testing' is possible for more teams. Proud of our work in AI, making Great Software Testing possible for ANY software team. Great Software Testing means better software, faster development, happier customers, and better outcomes for all. 

25

New Project! This project was done by me, Andrei Silva, Marco Rezon, Mateus Maciulevicius, Sidney Souza Junior and William Pereira Terra, while we all were on the buffer for Compass.uol project alocation, to put to use the knowledge we acquired on the period. This dashboard will will show all your finances, credit and debit operations, while giving the option to dowload individual entries if you so wish. You can also use filters to find specific operations. The dashboard comes with a profile edit where you can change your avatar and edit your info. It also comes with full dark mode support should you wish for it! Dependencies/technologies used: - Vite as a package manager and React project creator; - React TypeScript for all component creation with strong type support; - React-Router-Dom to route pages for an Single-Page Application; - React-Hook-Form to easier create react-compatible forms; - Tailwind for CSS styling speeding; - JSON-Server to simulate the back-end; - MaterialUI/BaseUI for some pre-made components and easier accessibility implementation; - ZOD for form validations; - Husky to padronize commits; - Storybook to create documentations for all components; - Vitest, React-Testing-Library and Cypress for testing (total coverage: 93%). The project was showcased today for all our colleagues on the buffer. We would like to thank everyone that watched our presentation and made it possible! Repository: https://lnkd.in/d7hG-EZ6 #keepcoding

29

1 comentário

💡💊 A Software Engineering Pill from Marcelo 💻✨ 💡 Go, A.K.A. Golang, was not designed to be an object-oriented programming (OOP) language. However, Go provides features for OOP, such as methods, interfaces, and code reuse. 📝 Here is an example demonstrating OOP principles in Go: package main import "fmt" // Define a struct type named BankAccount type BankAccount struct {   AccountHolder string   Balance    float64 } // Define a method Deposit for the BankAccount type func (ba *BankAccount) Deposit(amount float64) {   ba.Balance = amount   fmt.Printf("%s deposited $%.2f. New balance: $%.2f\n", ba.AccountHolder, amount, ba.Balance) } // Define a method Withdraw for the BankAccount type func (ba *BankAccount) Withdraw(amount float64) {   if amount > ba.Balance {     fmt.Printf("%s has insufficient funds to withdraw $%.2f\n", ba.AccountHolder, amount)   } else {     ba.Balance -= amount     fmt.Printf("%s withdrew $%.2f. New balance: $%.2f\n", ba.AccountHolder, amount, ba.Balance)   } } // Define an interface named Account type Account interface {   Deposit(amount float64)   Withdraw(amount float64) } // Define another struct type named SavingsAccount that embeds BankAccount type SavingsAccount struct {   BankAccount   InterestRate float64 } // Define a method AddInterest for the SavingsAccount type func (sa *SavingsAccount) AddInterest() {   interest := sa.Balance * sa.InterestRate / 100   sa.Deposit(interest)   fmt.Printf("Interest of $%.2f added to %s's savings account\n", interest, sa.AccountHolder) } func main() {   // Create an instance of BankAccount   account := BankAccount{AccountHolder: "John Doe", Balance: 1000.0}   account.Deposit(500)   account.Withdraw(200)   // Create an instance of SavingsAccount   savings := SavingsAccount{     BankAccount: BankAccount{AccountHolder: "Jane Doe", Balance: 2000.0},     InterestRate: 5.0,   }   savings.Deposit(1000)   savings.AddInterest()   // Use an interface to call the Deposit and Withdraw methods   var acc Account   acc = &account   acc.Deposit(300)   acc.Withdraw(150)   acc = &savings   acc.Deposit(500)   acc.Withdraw(700) } 📖 Explanation: ✨ Structs as Objects: BankAccount is a struct with fields AccountHolder and Balance and SavingsAccount embeds BankAccount and adds an InterestRate field. ✨ Methods: Methods Deposit and Withdraw are defined for the BankAccount type and Method AddInterest is defined for the SavingsAccount type, which uses Deposit to add interest to the balance. ✨ Interfaces: Account interface requires Deposit and Withdraw methods. Both BankAccount and SavingsAccount implement this interface. ✨ Composition over Inheritance: SavingsAccount embeds BankAccount, allowing it to reuse BankAccount's methods and fields while adding its own AddInterest method. ✨ Polymorphism: The Account interface allows different types (BankAccount and SavingsAccount) to be used interchangeably based on the behavior they implement. #Go #Golang #Programming #SoftwareEngineering

2

🚀 Esta é uma pergunta que frequentemente surge ao implementar APIs com bancos de dados, usar ORMs de terceiros, criar nossos próprios ORMs, criar consultas SQL... Neste repositório, iniciei um estudo sobre o desempenho de acesso a bancos de dados em Golang! Comparamos três abordagens comuns: consulta SQL única, CRUD DAO e GORM ORM. Todas testados com PostgreSQL. Os resultados destacam diferenças significativas em eficiência e uso de recursos. Vale ressaltar que, em todos os casos, devemos nos preocupar com a segurança. 🐹💻 🔍 Destaques da comparação: - Consulta SQL Única: Mais eficiente em tempo de execução e uso de memória. - CRUD DAO: Uso moderado de memória, mas mais lento. - GORM: Mais fácil para desenvolvimento, mas maior tempo de execução e consumo de recursos. A documentação está disponível em português e inglês. 📊 Confira os resultados e o projeto no GitHub: https://lnkd.in/dhti4bXW Há muito mais testes a serem feitos. Qualquer feedback ou sugestão são bem vindos! #Golang #DatabasePerformance #PostgreSQL #SQL #GORM #SoftwareDevelopment #Benchmarks #DataScience #Coding #TechResearch #Docker #Python #ORM #CRUD

4