In this article, I will give you the tips that helped me the most, working as a software engineer. These are tips I wish someone would have told me earlier.

Read Effectively

It’s important that you learn how to read and more importantly comprehend written media like books, documentation, notes, articles, etc. Videos and tutorials are great, but due to their nature, they can’t be “detail dense” like books or technical documentation. Reading effectively is a skill you can develop. Paying attention to details and properly absorbing text while making mental models, in a way that doesn’t take too much time, is an invaluable skill.

One great way to start is to look at sites like Medium or Reddit. One can start there and then progress to technology books.

Write Effectively

Knowledge transfer during the software development lifecycle requires scalability. If you are going to work with others, you need to be able to share your ideas. Writing is one of the most effective ways of sharing deep technical knowledge.

When working for medium to large tech companies, because there is so much information it’s impractical to verbally explain things whether in person or through videos.

Learning to write effectively also expands your sphere of influence in those places and improves your visibility on the internet which improves your odds of getting found by recruiters.

Writing also helps you to properly crystallize your thoughts, forces you to streamline concepts in your mind and sharpens your thinking.

To get started, you can start with writing technical articles on Medium or for personal ideas, Note-taking apps like Obsidian. Writing in a way that is easy to read is also very important. Proper spacing, Paragraphs, Use of Diagrams, etc. These things go a long way in making your writing pleasant to read, which is one of the goals of writing.

Plan Everything

Make plans for everything. Plan your Standups, Sprints, One-on-Ones, Workdays, etc. Planning helps you look for signals in all the noise of working day to day. Hopefully, you’ve been writing things down at this point so you should have enough information written down to come up with effective plans.

The plan doesn’t need to be perfect. Just have a plan. There’s a chess saying, “A poor plan is better than no plan at all”. Planning also means that everything you say or do is more impactful because there is some thought behind it. Stop improvising!

Improve your Time Management

As a Software Engineer, your time is by far your most valuable resource. As you grow in your career, this value grows exponentially. Accompanying this growth, the demand for your time also grows exponentially, from Peers, Junior Devs, PMs, Managers etc. You must manage your time effectively so that you not only have time to pour into these areas but also into personal development. Here are some tools to improve your time management skills.

Schedule

A Schedule is very important to prevent conflicts in meeting times and help you plan your day/week accordingly. Knowing what you have scheduled in the future allows you to plan properly for them. It’s pretty common practice in the industry now for companies to have a shared calendar so you can just use whatever your company uses.

Routine

Having a set routine gives you a structure to manage the chaos that comes with the increase in demand for your time. Routines also help you to build good habits that will pay off big in the long run. For example, when I was in Lagos, Nigeria. I used to have 2-hour commutes to work. I made it a routine to read a book or listen to a podcast on my way to work and in a Year, I had learned so much and read so many books, it was unreal.

A routine also allows you to properly disconnect without feeling guilty. Your nervous system will thank you for it.

Prioritize

Knowing how to properly prioritize your time is critical. Often developers create a schedule for the day like Wishlist. This happens especially during standups or sprint planning. They try to shove everything they wish to accomplish into the plan. But the reality is that you probably will only complete some of it. Now, you have probably made commitments based on your “Wishlist” and then must go back on your word when it’s too late.

To be more effective, your plan should not be a “Wishlist”. It should only contain the things you can ACTUALLY finish. If you are not consistently finishing the items in your schedule, then reduce the scope of your schedule. Avoid the “Urgency” trap. This advice also applies to teams as well, not just individual developers. Bringing one task/idea to completion on time beats having 5 tasks constantly spinning and delivering them late.

Completing Tasks also has the added benefit of producing a Dopamine/Morale boost. Constant Context Switching on the other hand is a terrible punishment and it robs you of a sense of accomplishment and that quickly leads to severe burnout.

Build and Maintain Focus/Momentum

It’s very easy to think that our mental resources are infinite. We think we can summon motivation, focus, determination, etc. at will. We think these things just appear out of the ether. So, there must be an infinite supply. This is categorically false. We have a very finite amount of these resources and paying attention whenever we feel motivated to build is critical.

Entering a state of flow as a developer is like getting a multiplier in a video game. A Higher multiplier makes it easier to reach a higher score. In the same vein getting into a state of flow makes accomplishing bigger and bigger tasks easier.

The sad part is this state of flow is a very fragile thing. Distractions, Context Switching, and Interruptions can kill this state. One reason Planning and Time management skills are important is so you can get into this state of flow quickly and maintain it for longer periods.

It is also important to remember that motivation and flow state are connected to momentum. So, motivation is never going to come to you in a state of rest. JUST... GET... STARTED and the motivation will meet you along the way as you gain momentum.

Once you have this momentum, Protect it. Make a conscious effort to minimize distractions and then push as much as you can. Pay attention every time you enter the flow state. Pay attention to the things that helped you get into that flow state as well. For me, coffee and music help me get into flow quickly.

Learn to Dig Deep

“The Magic you’re looking for is in the work you’re avoiding” — Chris Williamson

There’s no better way to put this. To become an effective software developer, you must be willing to dig deep into the technologies you use. You need to understand the nitty-gritty of how your technology stack is put together.

How well do you understand the frameworks you use daily? Do you understand how they work on an intricate level? Have you browsed through their code/documentation?

This is important because when you hit novel problems or get into situations where your application is producing unexpected behavior, your deep understanding of the technology is what will get you through those humps.

There’s no easy workaround to obtain deep knowledge, you have to plan and make time to dig deep and research to gain that knowledge.

Know When and How to Seek Help

In the beginning, when you are learning to code, it is mostly a solo effort. However, in the real world, Programming is a Team sport. Like I said earlier, Great things are rarely done by individuals. Collaboration is key. One area of collaboration is knowing when you need the help of others and how to ask for that help.

Know when to ask for help.

It is not wise to spend weeks on a problem that a colleague can easily unblock you on. Being able to identify when you are spinning wheels on a particular problem or when you start spiraling into despair. In that moment it is important to keep your Ego aside and seek help.

Exhaust all the options you can think of first.

But there is a balance here. You need to be respectful of our colleagues’ time. You must first exhaust all the obvious remedies or troubleshooting steps before asking for help, that way you make it easier for them to solve your problem because they can skip the obvious steps.

A second reason for this is that at times, trying the obvious thing might solve the problem and you are now better off for it.

Always include all the relevant context

Don’t just ask questions that lack context like “I ran the build locally and it was crashing with XYZ Exception”. This is a terrible way to seek help because it lacks all the necessary context the reader might need to help you.

A Better way is to add not just the context of what you are trying to achieve, but what steps you’ve taken and their outcomes and then the specific part where you are stuck for example.

“I am trying to reproduce the checkout bug and I ran the latest build locally. However, I am getting XYZ Exception at the GetCartItems method. I tried passing in valid sample data, but I am still getting the same exception. Here is the full stack trace and here is the link to the logs.”

This makes it easier for the reader to help diagnose the issue and the context helps them know if your entire approach is wrong in the first place.

Leverage existing Resources.

Tools like Stackoverflow, Internal Technical Docs, troubleshooting guides, or even AI like ChatGPT (use wisely) are great ways of getting help on very common use cases. More often than not, someone else has experienced the same problem you are stuck on, and these resources are great for quickly getting you unblocked without requiring the time of your colleagues

Conclusion

These tips are things that I not only do myself but see most high-achieving software engineers doing that easily sets them apart.

There are more tips but those are mostly subjective and depend on the level/character of the individual. However, If you can do these 7 things, I assure you that you will see results in how well you can deliver value as a Software Engineer

One of the most underrated features of F# is Type Providers. The “magical” tool that creates types on the fly using information that the compiler has pulled from a data source.

Why Type Providers?

For example, Imagine you are to consume a REST endpoint that returns JSON. Typically in a statically typed language, you’d have to physically inspect the JSON returned from the endpoint and then create classes that correspond to the schema. After that, you can then make the call and deserialize the response into the corresponding types that you created.

This is a lot of work for just consuming a data source. In a dynamic language, those steps are avoided altogether and you just access properties directly. The downside is you don’t have any guarantees or safety about your code that calls that endpoint. Add that to the fact that IDEs and tools can’t help you here and you just have to trust that you wrote the code correctly. If not, you’ll find out at runtime.

Type Providers give the best of both worlds. The compiler does all the creation of classes and also does the deserialization for you. That way, you can just access data the same way dynamic languages do but still have the type safety that comes with static languages.

The Problem — Continuous Integration

Type Providers are awesome until you want to do continuous integration. Where you want a build server to build your code in isolation. It may or may not have access to your database or API endpoint. Even if you could get that to work somehow. It violates one of the key principles of Continuous Integration which is the idea of having Repeatable Builds.

“Repeatable Builds” is the idea that given the same source code and build environment, the build output/outcome should remain the same.

This becomes a problem because our compiler just used data from somewhere other than our source code in order to build our code.

Luckily, there is a workaround for simpler type providers like the JSON Type-Provider where you can copy a sample output to a JSON file and then point the type-provider to that one instead.

However, it becomes tricky when dealing with a database. How do you encode the database schema into a file? I had this problem when I set up continuous integration for one of my projects. In the project, I used the SqlDataConnection Type Provider which is based on LINQ to SQL behind the scenes.

After inspecting the Type Provider API, I noticed that it takes a DBML file (Database Markup Language). This is a description of the database in XML.

The new challenge is now generating a DBML file because there’s no way I’m crafting it by hand.

Well it turns out there is a tool called SQLMetal that comes with the .NET SDK

The Solution

Step 1: Copy SQL Metal

Go to “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.1 Tools” or similar directory, copy out sqlmetal.exe into a folder in your project and also check it into source control. In the case of the Dumia project, I put it in “./utils/sqlmetal.exe”

Step 2: Invoke it during migrations

Because it dumps the schema of the database as a DBML file, you need to invoke it whenever the schema changes. Luckily I use FluentMigrator so, in my migration script, I added the call to SQL Metal as follows

This dumps the DBML file in the Infrastructure project

Step 3: Point the Type Provider to the schema file

Next, we need to make our type provider point to the schema file (DBML) that we’ve generated so that it can take our types from that file. This means that we can change the file, the compiler will use that version of the file to build. which pretty much ensures that we’d have repeatable builds.

To do this we simply pass it as an extra type parameter

and Voila! you are done. Now when the application is built on a build server, it will use the dbml however at run-time it will the connection string instead.
The full source code is available at the Dumia project github repo

Conclusion

This might feel like you are losing some of the flexibility of Type Providers but not necessarily. First of all, you can easily generate the schema data whether by dumping a JSON file or generating a DBML. Secondly, changes to the schema file are much simpler than changing raw source code.

Ultimately, if you are experimenting and exploring data then you will get the most out of using Type Providers the way it is out of the box. But if you are writing production level code that needs to be reliable, then you need to have someway of codifying the schema because it should be part of your source control and built by your CI/CD Pipeline.

Continuous Integration with Type Providers was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

Happy New Year! Its been over a year since I started working with F#, Learning the language and improving my skills, looking back I realize that I’ve come a long way from being totally puzzled about the language to now understanding it intuitively and even contributing to the Visual F# Compiler. That said, I decided to write this blog post about things that I wished I knew or that I wished someone had told me before I started this Journey.

1. It is easy to learn

Right off the bat. This is by far the biggest misconception about F#. The idea that F# is difficult to learn. But that’s simply not true. F# strives for symmetry. This means that the language is built on very few powerful low-level constructs/abstractions and the advanced ideas are derived from those.

For example in F#, The let keyword allows you to perform what is called a binding. Once you fully understand the let keyword, you can create functions, values, perform basic pattern matching e.t.c. With the knowledge of the let keyword alone, you can get A LOT of things done. That’s true for a lot of fsharp. Once you learn a few keywords/constructs in F# you can get a lot of things done. Or at the very least it’s easy to understand a lot of things.

In PDC 2008 Luca Bolognese did just that. He taught what is probably the 40% of F# that you’ll use 80% of the time in roughly an hour.

2. It is VERY typesafe

It all boils down to one thing. How much confidence do you have in “Build Succeeded”?

Here’s an analogy. Imagine implementing a really complicated algorithm. Now Imagine having to implement the said algorithm in raw JavaScript. The refactoring nightmare, having to write tests to make sure the right parameters are passed. Imagine all the defensive code you have to write to separate null/undefined.

Then Imagine the amount of relief you’d get moving from raw JavaScript to Typescript. And the sanity/safety that it gives you. The fact that you can now focus on writing more targeted tests and leaving off the mundane things. Imagine all the tooling upgrades you get with that.

Now imagine re-implementing the said algorithm on the back-end with something like C# with stronger type-safety and much less unpredictable run-time behavior. F# is the next evolution in that chain.

The F# compiler checks for missing cases in logic. With the magic of Type Providers, It can even check and validate connection strings, SQL statements, application settings e.t.c. This almost gives the feeling of “If it builds, either what you are trying to accomplish is wrong or it will work correctly”. The chances of having runtime errors are even smaller.

3. It encourages experimentation

F# comes from a rich history of functional languages. These languages came from Academia as a result, they are designed to be exploratory or should I say “Scripty”. In other words, they encourage experimentation.

F# has a tool called FSharp Interactive (FSI). It’s an environment where the line between compile-time and runtime is blurred. It’s very similar to something like LinqPad in the sense that you can quickly write code and execute them immediately. However, unlike LinqPad, FSI is an interactive space. You run some code, create objects and functions and these things stay in memory. You add some more code and run them and see the results. It’s a very different way of thinking.

In some ways, it’s taking the good ideas behind Test Driven Development (TDD) to their logical conclusion. That’s because when you are done experimenting with the code, you can easily extract the code you’ve “tested” into your application and take the running logic into your tests and then you can repeat the cycle.

Granted, C# now has this feature in what is called C# interactive but in my opinion, it is not as effective as FSI. That’s because F# was designed from the ground up to be used this way. In F# EVERYTHING is an expression, therefore, every piece of an F# program can be evaluated. This is common in scripting languages and it’s interesting to note that F# retains all this while being very strongly typed.

4. It can be very intuitive

The real reason F# looks cryptic at first is that its coming from a different family of languages and we aren’t used to writing code that way. If you are coming from any of the other functional languages like Haskell, OCaml or even python, F# will be very intuitive. Its akin to moving from C++ or Java to C#. The only reason it looks cryptic is that it’s not part of the C-Like Family which has dominated our industry for decades. After about a month of learning, It didn’t seem cryptic at all.

The Symbols in F# have almost universal meanings in the world of functional programming like (>> or |>). It is no more cryptic than !=, == or <>. After the initial “syntax shock” (which is normal by the way) you’ll start to see that a lot of ideas can be expressed in F# quite intuitively.

Also, some problems are much easier to come up with functional solutions because it’s closer to the way we humans think.

Take binding for example, When you say to a layperson that “x = 3”. To them, it means that x is actually 3. Not assigning 3 to x. Another example would be repetition. To “repeat” means to “do again” not increment a variable and check for a condition... Do you see what I mean?

5. It shuns ceremony

In addition to F# encouraging experimentation, the F# language also shuns ceremony. The language was designed to be tight, concise and straight to the point. Unlike “C-like” languages, it shuns curly braces, semi-colons and superfluous keywords like new.

A simple C# program contains a namespace, class and a static method, F# shuns all those and makes them optional. In C# you typically want classes to be public, so in F# they made public the default. That way you don’t need to type public all the time.

At the language level, little things like tuples, records and discriminated unions dramatically cut down the amount of code it takes to express common ideas and concepts.

At a higher level of implementing specific features, F# uses the Type Provider language feature to cut down the amount of ceremony it takes in connecting to a database and using it. Or even fetching data from a REST API amongst other things.

At an architectural level, F# shuns the ceremony of creating an Interface/Implementation pair just to have the ability to hide implementation details. You can simply just pass functions rather than creating an interface that has only one method in it. In other words, the method signature IS the interface. It typically tells you everything you need to know about the function

6. Easier to Test

There is a deeper difference between the Object Oriented and Functional Paradigms. It boils down to Encapsulation vs Composition. I wrote about this in the post “Fitting the pieces together”

Long story short, Functional programming in general focuses on combining smaller isolated things into bigger things.

If you look at the SOLID principles of Object Oriented Design at a very high level, you’ll see that it’s trying to isolate Object Oriented code so that you can test them. The idea of having rich domain objects that had every functionality that we wanted leads to an untestable clog of code.

Functional programming by default lends itself to be easily testable. Partly because every component is already isolated to begin with as opposed to hiding things behind interfaces and having to mock everything.

Mark Seemann did a talk on this “Look, No Mocks! Functional TDD with F#”

That said, Encapsulation is still good for some problems.. an example is building GUIs or Abstract DataTypes (ADT) but we took the encapsulation hammer and used it to knock every problem.

7. VERY Friendly Community

I’ve been part of several communities from Ruby, Angular, NodeJS, C# e.t.c. and so far the F# community has become the gold standard for me in terms of community. They are welcoming and always happy to help. For example, there is the F# mentorship program where an experienced developer will volunteer time to help you get a better grasp of the language and I have benefited immensely from it. Like seriously, can you show me any community that does this?

There’s also the Slack community where you can meet and discuss with other community members.

Jorge Fioranelli on Twitter

fsharp heroes at #OpenFSharp conference: @kot_2010 @enricosada @_cartermp @isaac_abraham &amp; @TRikace congratulations to all!

8. It will open your mind to possibilities

F# has a lot of tools in its toolbox. For example, Something as simple as a discriminated union has no direct mental translation in C# and Java. The closest explanation is a class hierarchy. But that doesn’t explain much. However, It is a very powerful tool when modeling domains. If you haven’t used it, It’s difficult to show you the value the same way it’s difficult to show a Pascal/C programmer the value of a class in Java.

Learning F# will help make you a better programmer overall not just in C# or Java. You will see new patterns for solving problems and it helps you to mature your skills.

Conclusion — Don’t be Afraid

Ultimately the most important thing I wished someone had told me is.. “Don’t be afraid”. Being a self-taught developer, I don’t consider myself a Maths wizard. I’ve always had the idea that F# is good for Mathematicians. But in the end, It’s just a .NET Language like Powershell.

PS — Speaking of Powershell, I had absolutely no problems learning Powershell. That’s funny because F# and Powershell share A LOT in common. Its also a functional, scripting language with similar features like pipelining, shadowing, composition e.t.c. and yet I was able to pick it up in very little time.

Eight reasons to learn F# was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

Step 1 — Get Visual Studio + Tools

So to get started you need to get Visual Studio 2017. There is a Community Edition which is absolutely free. But if you already have Professional or Enterprise, that will work too.

You need to install

• F# Language Support
• Visual Studio Extension Development Workload

Its a web setup so it might take a while. But once it’s done, you can now move on to the next stage

Step 2 — Clone the Visual F# Repository

The next step is to clone/fork the Visual F# Repository After cloning, you can checkout any branch you wish. For the sake of this walk-through, I will checkout feature/fmt branch which adds Auto Formatting to the Visual F# Editor.

Step 3 — Restore and Build Repository

Contrary to what you might think, you can’t just jump in and open one of the Solution Files and start Hacking away. You will need to build it from the command line.

However, the way to reliably build it is to Build it from the “Developer Command Prompt for VS 2017” just search for that from the Start Menu and You’ll see it. Also you need to right-click and run it as administrator

Its from this prompt that you should navigate to the directory that you cloned and then run

build.cmd vs debug

This will restore all the packages and run all build scripts. So.. It going to take a while. When it’s done, you’ll see something like

Step 4: Run Visual Studio Tools

You can now Launch Visual Studio open the VisualFsharp.sln file and setup VisualFSharpOpenSource as your default project and you are good to go. You could also just right-click and debug and it will launch a new instance of Visual Studio which has the your custom build of the Visual FSharp vsix loaded and you can debug the Visual F# Compiler and Tools.

If you have Visual Studio Enterprise, you could use Code Map tool to look at the projects and see they way they all fit together. I have created a snapshot I have removed the unnecessary projects.

Conclusion

I hope this post has been helpful in showing the steps to building and running the F# Tools. Its no where as scary as I thought it. If you want to help out you start by looking at the issues marked “Up for Grabs” and sending pull requests. If you still have any problems with the Steps mentioned above, you can reach me on twitter @odytrice

Contributing to the F# Compiler Service was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s been over a year since I started my Journey into F#. In this time, I have gained a lot of Experience in both the language and the community. I have also finished what is now one of my favorite Technical Books — Expert F#. I can now say that I have a good grasp of the Language. I’ve even been on a few podcasts like Functional Geekery and Developer on Fire.

F# is not like C# in many ways but more importantly the F# Community and Ecosystem is different from the C# Ecosystem. There are definitely overlaps because they are both part of the .NET Ecosystem. However, The F# Ecosystem has a strong emphasis on Open Source and community

The F# Community is mainly a group of passionate people of all skill levels that come together to develop the platforms, tools, libraries.. Everything. Microsoft for the most part isn’t directly involved in F#

This distinction means that F# is for the community and owned by the community. Historically, It put the F# Ecosystem in a awkward middle position. Most Non-Microsoft folks saw the Language as too “Microsofty” and even the “Microsofties” saw it as “Fringe” and were only interested in what Microsoft blessed which is C#.

However, things are changing rapidly.. starting from Microsoft. The current change that is the shift away from their “Windows-only” focus has rippled from the head across the company to the ecosystems that they play in. Now you have Microsoft as a Member of the Linux Foundation, Google joining the .NET Foundation, .NET becoming Cross platform and open source with .NET Core, Powershell running on Linux, SQLServer running on Linux. We are in a crucial moment in .NET.. nay Software Development history.

All this is causing a .NET Renaissance and many people both non-.NET and traditional .NET Developers like myself are starting to notice. Add the current wave of interest in functional programming and you find that many people are now looking at F# than ever before

As one of the people who has a deep love for the F# Language. It makes me sad when I don’t see support for something in F# and that’s normal because we expect Microsoft to push F#. After all its part of the .NET Ecosystem especially when we are coming to it from C#.

However, It’s also an opportunity! We should stop complaining and build what we want to see. Create what we want and contribute back to the community that’s how this great language was started and that’s how we will sustain it. There are already many awesome examples of this like Fable which is an F# to JavaScript compiler or even Giraffe which is a Native Functional ASP.NET Core Framework

Where do I start from?

The F# compiler is an awesome piece of software. Every time Its excellent type system kicks in, I’m in awe. It feels a bit like having a conversation with an AI about your code. It will infer things you didn’t think of ahead of time. In fact, You could stumble your way to a solution and the Compiler will guide you. That said, I assumed that I would not be able to comprehend the code talk less of contribute to it.

I have been feeling this strongly about it for a while now and have always desired to contribute to it somehow. When the F# mentorship program started I was eager to get someone from the community to help me understand the F# Compiler and Tools. And thankfully, I was paired with Avi Avni and he was gracious enough to help get the compiler development tool chain setup so that I can run a local build of the compiler and editor. I was able to Launch VS in VS and debug the local build of the Tools

Get Involved

It might seem daunting and it’s a big commitment. However, irrespective of your skill level, there is a Project on Github (Like Nikeza) you can help with even if it’s just issue triaging. And by contributing we not only improve our skills, we also make the F# Ecosystem what we want it to be. There is no “Company” we have to wait for to build functionality/framework we want. It’s very busy people like you and me who have lives that are giving this labor of love. For the love of Language, For the love of Ecosystem, For the love of the Community.

PS - In my next blog post which is coming soon, I will show how to contribute to the F# Compiler/Tools. And maybe.. Just maybe.. I could build cool stuff like the Slack FSI bot

The F# Community was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

Back in October, I blogged about Using F# with .NET Core The tooling at the time was still a release candidate. Well a lot of things under the hood have changed about the tooling. There was the move from project.json to MsBuild which caused quite a bit of controversy.

That said, there were significant changes to the tooling. All the application models and frameworks are exactly the same.

To demonstrate the changes, I’ve made this short video to show some of the changes that were made to the .NET Core Tooling.

Highlights

No More Project.json

Project.json was meant to be a new project system/file format. It was quite awesome. However, It was designed for a strictly web server environment and didn’t play well with the existing .NET codebases. Here are some reasons:

• A project.json class library from a regular .NET Application, you had to first compile it into a Nuget package and then host said package on Nuget. Referencing exisiting .NET DLLs required the same hassle which was too much to ask.
• Project.json wasn’t extensible and lacked some of features like including settings from other files and incremental compilation. Features that were already in MsBuild
• It would mean a complete re-write of a lot of build systems and tooling not just for Microsoft but for the ecosystem as a whole.

That said, the team decided to overhaul MsBuild with all the nice features of project.json and they were able to come up with in what is in my opinion the best of both worlds.

All the cruft has been tucked away leaving only the really important bits

Welcome back, Solution Files

One of the advantages of moving back to MsBuild is that we now have the ability of build and restore multiple projects simultaneously. We can accomplish this by creating a solution file and registering our project files (fsproj) in it. That way, when you use dotnet restore at the solution file level it will restore all packages in that solution without you having to do it for each project.

Typically we use Visual Studio to manage solution files but now a command line utility helps us manage them.

• dotnet new sln — Creates a new Solution file
• dotnet sln add path/to/fsproj — Adds a new F# project to the solution
• dotnet sln remove path/to/fsproj — Removes an F# project from the solution
• dotnet sln list — Shows list of projects registered in the solution

Project Referencing

Referencing other projects is pretty much the same with the regular MsBuild. Except that MsBuild now supports referencing Nuget Packages directly

Again, you can also add packages or projects from the command line. Note that you need to be in the project directory (directory with fsproj)

• dotnet add package NugetPackageId — Adds a new Nuget Package to a project
• dotnet add reference path/to/fsproj — Adds a project reference to another project file

Conclusion

Like I said in the last post, All the .NET Core tools for building real world applications using F# are available and ready. You can use all the existing frameworks and libraries and tools without much friction.

We are even starting to see innovation from the community like the Giraffe framework, which is an F# web framework for asp.net core. It replaces the Object Oriented Asp.Net Core MVC with a Functional framework. But still plugs in to the already existing eco-system of middleware and tools available for .NET Core. He also has a blog post detailing the rationale/tutorial for the framework. Its worth checking out

.NET Core 1.0 Update for F# Tooling was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m kind of a music nerd and I’m a fan of all kinds of music from Hip-Hop to Classical music. As a developer, I always listen to music while I work. And I strive for the highest music quality and seek out the best listening experience.

Context

I am currently living in Lagos, Nigeria. And as music services go, We don’t have Spotify or Google Play Music. We have only Apple’s iTunes and Microsoft’s Groove Music. That said iTunes is my Go-To service for purchasing and listening to music.

Recently, Nigeria entered into a recession and the Dynamic Currency Conversion (DCC) was banned. Some banks put a $100 limit on debit cards for native dollar transactions while others ban it completely. Apple recently switched to using DCC which means that I can not pay for my iTunes subscription anymore (Talk about having a first-world problem in a third-world country. *laughs*)

All this lead to Apple cancelling my subscription and with it, yanking off tracks from my playlists automatically. However, I was able to extract my original playlist data from one of my systems by not connecting to the internet and then using the export function in iTunes.

Problem

I was able to export all of my iTunes data but to put it lightly, it is the most horrendous piece of XML ever created. Doubt it? Let’s take a look shall we?

Explaining all the flaws of this XML format is worthy of it’s own blog post. However, what I will say is that enforcing the order of child elements in XML is (to quote James Gosling) “the work of the Devil”

My Goal was simply to extract all of my playlist information from the XML. That way I could figure out how to migrate to another Music Service or even roll out my own.

Domain Modelling

Any experienced programmer will tell you that data structures are very important in solving problems. In fact Linus Torvalds once said

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important.

This fact couldn’t get any clearer after I botched the initial domain model by trying to model the tags rather than the data structures they represented.

For starters, I called the Discriminated Union PList which was wrong because Integer, Date, String… aren’t types of PList. None was my way of describing any Tag I could not understand which is a lazy way of trying to model the Domain. A Domain model should be as exhaustive as possible. Also Key isn’t exactly part of the domain. It isn’t a type of value.

Because of this, coming up with a algorithm to parse the document ended up becoming more difficult than I imagined. Using this domain I had the following implementation for parsing the data.

Suffice to say, I was heading no where fast. However, it had a few clever ideas like using pattern matching on line 13 to pick the child elements in twos. I also tried treating dict and array as special PLists with their own match cases which was just plain wrong.

Solution

One of the reasons that I decided to model the elements rather than the domain was because of the complexity of dict and arrays. Dictionaries contain key value pairs. And these values could also be other Dictionaries. The second image really shows this point

That’s when it clicked that Arrays and Dictionaries are simply Values not PLists. Hence the following:

With my data structure now nailed down, I couldn’t think of a way of solving the value parsing problem without thinking of the dictionary/array parsing and vice-versa. I immediately recognized that this was a chicken and egg problem.

Ody Mbegbu on Twitter

The solution to the Chicken and Egg problem is to lazily evaluate the Chicken #functionalprogramming #FSharp

In F# you can model this kind of chicken and egg problems using mutually recursive functions. That way, I can delay the implementation of parsing the Dictionary (toDict) and then recursively call (toValue) in it’s implementation. And it worked like a charm!

Line 10 shows where I call toDict whose implementation doesn’t exist yet and then in its implementation on Line 17 I can now call toValue for each of the children elements.

Conclusion

It might seem obvious but I’ll say it anyway. Your choice of data structures and how you design your domain is crucial when writing code in F# (or in any other language). Screw it up, and you will be walking around in circles. Nail it, and your implementation will be concise, straightforward and probably even trivial.

Here is the final Source Code

The full source with a sample xml file is also available on GitHub

Parsing iTunes XML Data with F# was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

Well I am going to try and break that curse. This blog is dedicated to people who just want to build real world applications and aren’t exactly interested in Academic Exercises. So I’m going to save you all the mystery and try to explain it in three simple things.

1. Type Amplification
2. Chaining Computation
3. Chaining Computation on Amplified Types

Type Amplification

Type amplification is the “lifting” of types into a context. It’s sort of a Type wrapper. See the example below:

You can then say that the Monad<T> is an amplified type. But for this to be useful, we need some way/function that will allow us to convert values of any type into values of the Monad. This function is called the Unit Function. Let’s see some examples.

The rule goes that once you’ve lifted a type, you can’t get the original value back.

An analogy would be paying cash to the bank. Once the cashier takes the money from you and credits your account, you can’t get the original cash back.

But then how do I spend my Monad if I can’t get my value back?

Chaining Computations

The same way banks give you credit cards to spend your money, Monads provide a way of doing stuff with your values. This is the Map function. This function allows you to do with the Monad whatever you would have done with the original value.

This is really cool because we can perform all our computations on amplified types which gives us a lot of flexibility. “So can we now replace all references to raw values with their Monad counterparts?”.. Erm.. Not quite. We currently have no way to perform computation on two Monads.

Chaining Computation on Amplified Types

From the last example, what if I wanted to subtract result1 from result2? I have no way of getting at their internal value. So what’s next? Well that’s where the Bind method comes into play

That’s it! Bind is typically called the “God Function”

That’s because in conjunction with the Unit function, you can express/do just about anything. For example, you can re-create the Map function by calling bind on a function that take the Monad’s value and amplifies the result of the computation. See below:

This is really Cool Stuff.. But what’s the value of all this?

This principle of performing computations on amplified types isn’t new and it might even be familiar. As a matter of fact, you’ve used them.. A LOT

Your favorite things like Seq/IEnumerable, Task, Observable and Option are all monads. Think about it, IEnumerable and Observable have SelectMany, Seq has collect, Task has ContinueWith, and Option has bind. IEnumerable amplifies values by having zero or more values, Task amplifies a value by resolving the value in the future. Option amplifies a value by letting you know it might be null, Observable amplifies types by firing multiple values as events. When you finally get to this realization, It fundamentally changes your perspective.

Monads and Purely functional Languages

Pure functional languages like Haskell use this trick to isolate impurity (side effects). Any function that talks to the outside world will return an IO Monad.

That way you can only chain computation on the monad but you never have direct access to the impure value and that keeps all your functions pure. It might seem like a hassle but the language has a bind operator and some other syntax sugar to make things simple.

F# provides what is called a Computation Expression to make things simpler. You have definitely used it before. e.g.

In fact, seq is not hard coded into the compiler. You can just as easily create your own expressions and the compiler does all the calls to bind for you.

Believe it or not, C# also provides something similar. And that‘s the LINQ Syntax. Anders Hejlsberg, Eric Meijer and co dressed a wolf in sheep clothing. Contrary to what you might think, the LINQ Syntax isn’t just for writing LINQ queries, you can use it to do Monad Computations (although in a limited manner). .

Conclusion

I really hope I was able to explain it in a way that almost anyone can understand. This pattern isn’t exclusive to functional languages like F#. You can use it in many mainstream languages like C#. I even wrote a library using the Monad pattern in C# (Operation Extensions) long before I started coding F#.

Understanding Monads was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

Update: The examples in this post used the project.json tooling. for information about using the newer fsproj, see this blog post.

.Net Core was released a few months ago and since then they have released just an update (1.0.1). Its still early days but even though the platform is still at it’s infancy, It’s been gaining momentum.

In the past series of blog post, I examined building applications with F# using the regular .Net Framework. The sample application Dumia had reached prototype stage but I wasn’t happy with the web development experience from a Pure F# perspective and had to make architectural sacrifices. I also couldn’t figure out an easy way to do database migrations without having to type everything from scratch.

This was around the time .NET Core tools were in development so I decided to jump on the bleeding edge. After all.. what could possibly go wrong? *smile*.

Anyway, from the little I played around with, I quickly realized that the personality and design of .NET Core better suits F# development. The fact that they detached “the tooling” from “the editing” (Visual Studio) means that it levels the playing field across all of the dotnet ecosystem and the CLR is much less “C# Language Runtime” and more “Common Language Runtime”

I was so excited and pumped that I’ve decided to port the existing Dumia Prototype to .NET Core using F# exclusively (Almost.. Technically Razor Templates are C#). The Project Manager in me cringes at the thought of changing technology in the middle of a project, especially one that just got released. But I’m doing this because in my mind, the Pros are much greater than the Cons and hopefully, this will serve as a blueprint for my future projects.

Let’s Do This!

I knew before I could start the port, I needed to know that I could tackle these three scenarios using .NET Core

1. Creating Web Applications
2. Creating and Referencing Class Libraries
3. Data Access (Including Database Migration Strategy)

Getting Started

First you need to download and install the Tools. Head over to dot.net/core and follow the instructions. Its the same for Windows, Mac and Linux. The only thing you’d do differently is to use the F# Language switch.

As for Editors/IDEs, Currently VSCode is the editor with the most .NET Core support. Everything is cross-platform and free so bring your Macs and Linux Machines along.

Here are the full instructions

Creating Web Applications

In .NET Core web applications are just console applications that host a Webserver inside them just like Ruby’s Rack or NodeJS. All you need to do is add the necessary packages and you are off to the races.. Except that its a lot of boiler plate to write. Thankfully, there are now yeoman generators available for these. Just install NodeJS (You’ll need it anyway to do front end work) and then run

npm install -g yo generator-aspnet

After that all you need to do is enter yo aspnet in the command line and you’ll see a kind of Command Line Interface you can use to pick the project type you want.. kind of like File > New Project. Something like this

The yeoman generator for ASP.NET currently supports scaffolding .NET Core F# Projects. In addition, there are plugins for VS Code and Atom so that you don’t need to type the commands yourself.

Creating and Referencing Class Libraries

Now that we have the ability to create and run web applications, the next step is layering and project separation.

In theory, a .NET Core dependency is just a dependency so the project doesn’t care if it depends on a Nuget Package or Source Folder. Its transparent to the build system. The beauty of this is that you could download the source for a Nuget Package and compile/debug against that without touching your code, which is pretty neat.

However you might want to restrict dependency to the Project Folder of dependent libraries. For this, all you need to do is create the project in the adjacent to the current project and and add the following line

“Project.Library”: { “target”: “project” }

This tells the .NET Core run-time to depend directly on the project folder adjacent to the current project. Technically, it could be anywhere on your machine, all you need to do is add the location to a global.json file

Data Access (Including Database Migration Strategy)

Data Access is an area of strength for F#. Type Providers are the idiomatic way to get access to data from F# and they are totally awesome.

However, when it comes to having managing changes over time to the schema of the database, There isn’t a good, easy way to do so. This is an example of an area where even though C# isn’t as good, the tooling helps give a better overall experience. Using C#, the tooling (typically Visual Studio) could look at you data access objects and create what is essentially a migration script but in code which you can check in to source control and at runtime the application can upgrade the database by itself. This saves you from mucking about with server credentials and writing update schemas. Unfortunately, this workflow hasn’t supported F# projects in the past.

To be clear, There are libraries like the Fluent Migrator that you could use. but you’d have to write the migration scripts in code by hand. Aside from being tedious initially, computing diffs between migrations is error prone if done by hand. Not to mention that it hasn’t been ported to .NET Core. Which leaves us with one option..

Entity Framework Core

Entity Framework Core is a complete rewrite from scratch of the popular Entity Framework or as it’s affectionately called “Entity Framework Magic Unicorn Edition”. I could go on and on but the key takeaway is that it’s tooling doesn’t depend on Visual Studio anymore.

To figure out how this would work with F#, I took Julie Lerman’s course on Pluralsight (Play by Play: EF Core 1.0: First Look) but the twist was to try and do everything using only F#. I sensed that it would be a difficult undertaking and so that I couldn’t talk myself out of it, I tweeted

Ody Mbegbu on Twitter

Watching @julielerman EF Core Course and following along using F# :D

She was kind enough to respond (which blew my mind btw) and I promised that I would create an FSharp equivalent of her demo code and send her a pull request.

And boy was I in for a wild ride! Yes a lot of it went as expected. However, migrations were a bit tricky as the tool would emit C# code and I had to convert them by hand to F#. I also ran into problems trying to use quotations, I had to import a library and then trick the .NET core runtime to accept portable class libraries… and later realized that the F# compiler can automatically convert F# function expressions (fun x -> x.id) into Expression<Func<T>> just like C#.

After that huddle, I was able complete the translation of the migration code and execute it against the database. Here is a sample of the migration. Full source is available here

Verdict

All in all, my experience with .NET Core has been exciting. I hope, I’ve been able to show that all the tools are in place to build real world applications using F# and .NET Core and I’m also excited for the future of the platform. A good size of the F# community isn’t eager to make the jump yet (and for good reason) but the support is growing.

Using F# with .NET Core was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thinking about how to and where to put pieces together for the Dumia Application is easily the hardest part of putting this application together. Coming up with a nice repeatable way to piece together an application using Functional Language like F# requires a real change of thinking.

Paradigm Shift — Encapsulation vs Isolation

Before we go into the details of assembling an Application with F# or any other true functional language for that matter, We need to understand the fundamental difference in philosophy between the Object Oriented world and the Functional World. This can be distilled down to two concepts.. Encapsulation and Isolation

Encapsulation

You see in OOP Land, you had a Box of tools (Classes) that had specific uses.

Each tool had inner workings and behavior that you the user is not meant to see. Sort of like a black box. The user needed to know

• How to instantiate it
• What method(s) to call
• What order to do the above

We would then assemble an application by connecting objects together either by letting objects create other objects or calling other objects. Because of this the user’s behavior depended on the expectation of the Objects it depended on. As a result of this, In practice, they were difficult to isolate which by definition meant that they were difficult to test because you needed to isolate code to test it.

To solve this, we relied on using Interfaces and Mocks to simulate not just the behavior but the character of the dependent object. These set of solutions led to the SOLID Principles of OOP Design. These exist primarily to make OOP code testable.

Isolation

With functional programming, You are dealing with Functions as the basic building block. Each function can be thought of as a lego brick

A pure function is by definition isolated. Unlike Encapsulation where an Object is trying to hide things from you, a pure function can not do anything It did not declare in its interface (or signature). You could say that a Pure function is “honest”

This causes a paradigm shift because You need to think of solving problems by breaking them down into these small isolated functions and then re-assembling them at your application entry point.

This might seem counter-intuitive at first but then when you open you mind to the possibilities, It fundamentally changes how you think about building software.

Because of my extensive background in Object-Oriented Languages, this paradigm shift produced so much Cognitive Dissonance about how to structure the Dumia Application that I literally had a sleepless night trying to resolve my old habits with the new paradigm

At Several Points in the design, I had to step back and think:

By taking this approach to application architecture, a lot of complexities fall away. You no longer need Interfaces, Mocks, Managers, Services, Presenters, Controllers and the list goes on. In fact, this image by Scott Wlaschin pretty much hits the nail on the head.

Having this in mind, I came up with a very simple functional architecture.

I was able to categorize functions into two camps and as such put them in two assemblies

• Domain — This contains functions that are “pure” business logic (or rules) which means that they don’t depend on the application environment (Web, Console, Mobile etc). These functions are typically pure and they just deal with transforming inputs and producing outputs. You should be able to take this code and move it from one environment to another easily
• Infrastructure — This group contains functions that need to either talk to the external world (e.g. DataAccess functions or SMS/Email functions) or work with external dependencies. (e.g. Cryptography library)

The beauty of functional programming is that you can plug these two together using just their function signatures as the interface between them.

An example of this is using Higher-Order functions (functions that take other functions as parameters) as a form of Polymorphism rather than interfaces.

For example instead of having an IEncryption interface that has an Encrypt function that takes a string and returns a string, It will be replaced with a function that takes a string and returns a string. This function is passed into any function that needs to encrypt strings.

See.. No IOC Containers/Interfaces needed.

Doing these, I ended up with something like this

Fitting the Pieces Together was originally published in Real World F# on Medium, where people are continuing the conversation by highlighting and responding to this story.