Skip to content
View fmaste's full-sized avatar
💭
I may be slow to respond.
💭
I may be slow to respond.

Highlights

  • Pro

Block or report fmaste

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 100 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
fmaste/README.md

Federico Mastellone

Education

B.S. in Computer Science Engineering, ITBA

Summary

I’m a Scrum Alliance Certified Scrum Developer and I have been following agile practices for many years, on-site or remotely with companies from different regions. I have worked in Java projects with the usual Hibernate/Struts frameworks and used all the object oriented patterns you can imagine, mostly when trying to make sense of big spaghetti PHP codebases. In the end I got tired of trying to make everything fit into objects and switched to functional programming to never look back!

Haskell

But mostly, I have been a silent participant of the Haskell community for more than 10 years. I made contributions to Haskell's Cabal package manager when I needed for a private project and read the most significant papers and books, from "A History of Haskell: Being Lazy with Class" to "Parallel and Concurrent Programming in Haskell"

Principles

“Premature optimization is the root of all evil”

Donald Knuth.

Always keep it simple and don’t overbuild.

If you're going to break something you better break it early, committing and merging often is a good practice and when an error is found it's complemented very well with git-bisect.

But to find errors you need proper testing, "Program testing can be used to show the presence of bugs, but never to show their absence!". So in addition to defining the base cases by induction with HUnit, I use QuickCheck and Hedgehog, that coupled GitHub Actions are your best friends. Evolving code without testing is dangerous!

The best way to evolve the code or understand legacy code is refactoring it, making small steps until it gets easier to understand and fix errors. When extracting, renaming, refactoring in general I follow the steps detailed in Martin Fowler's book Refactoring. Although it's mostly object oriented the methodology can still be applied to functional programming (The downside of doing small / atomic commits is that you have to remember to merge squash to keep the log uncluttered).

Having code that looks nice and everybody can understand is important. Style guidelines can vary from company to company (and generate a lot of bikeshedding) but I always try to be as standard as possible and use as few dependencies as possible (back to "don’t overbuild" mentioned at the begining).

External

Linkedin: https://www.linkedin.com/in/fmaste/

Pinned Loading

  1. caralibro caralibro Public

    A Facebook Java API

    Java 5 2

  2. crypto crypto Public

    Crypto Portfolio Research

    Haskell 1 1

  3. haragan haragan Public

    Haskell web framework for a multi master database

    1

  4. Helenium Helenium Public

    Selenium EDSL in Haskell

    Haskell 1

  5. jsMVC jsMVC Public

    A JavaScript MVC

    JavaScript 1

  6. Haskell Haskell Public

    A mixture of Haskell quick reference guide, research logbook and tutorial full of external references

    Haskell