In a lot of projects we wouldn't reference the objects directly, ever, and only reference the interfaces. There is more at stake than just the class implementation. An example will likely help: Let's assume I have a class that reads a record from the database. I call that class "DataReader." The problem with not having an interface is that any time I refer to that class, I have to understand it's dependencies as well. If it is ready from MySQL, it likely takes a dependency on MySQL drivers/packages. That means anything I write that uses that class now is dependent on MySQL. In reality, however, I may be writing a simple test on an object that just depends on the data reader. Why should that project have to take on additional dependencies? Then let's assume sales tasks me with building a "demo version" of the product that runs on their laptop that doesn't have MySQL. If my main code is talking to "DataReader" I'm stuck. If I implemented it as IDataReader, now I can write SalesDataReader that just returns a hard-coded/static value and I'm good to go. From a design perspective the interface allows you to describe what the expectations are for a set of operations without the implementation. I almost always start with interfaces, and then implement the classes as needed. This helps scale projects. Just one more example to help clarify: I was working on a project for a cable provider that involved building out a television guide. Unfortunately, they were migrating to a new database and rewriting their API implementation. We had data structures in place (i.e. a "program" looked like "this" and had "these fields") so we were able to write interfaces (fetch guide, fetch program, get ratings, etc.). Instead of waiting for the other refactoring to finish, we went ahead and created some "dummy" classes implementations that returned hard-coded shows and channels so we could get the user interface working and styled. Once the APIs came online, we simply swapped out the dummy classes with implementations that called to the APIs and "flipped the switch" to bring it live. So much power in using interfaces, I wouldn't skip them just because of assumptions around how they'll be used. Jeremy

I'm biased as an employee, but I believe that, all memes aside, there are some pretty solid commitments and statements being made that you should at least consider before drawing conclusions. My take on this is very positive and I'm excited to see how it evolves. Without further ado ... CEO Satya Nadella: https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/ The Linux Foundation: https://www.linuxfoundation.org/blog/microsoft-buys-github-the-linux-foundations-reaction/ Nat Friedman: https://natfriedman.github.io/hello/ ... and from his "ask me anything": https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman_future_ceo_of_github_ama/

The interface is a signature. It is a contract that implementations agree to adhere to. Using an interface, you have guarantees that certain properties or functions exist regardless of how the object is actually implemented. The class is an implementation. Unlike an interface, a class can be instantiated. It contains the behaviors of that class, as well as the implementations of any interface it extends. Classes can also participate in inheritance. For example, in my 6502 chipset emulator written in TypeScript (https://github.com/JeremyLikness/redux6502) the interface IOpCode is a contract that op-codes can implement: export interface IOpCode { name : string; value : OpCodeValue; mode : AddressingModes; size : Byte; execute : (cpu: ICpu) => void; } The base class is default behavior shared by all op codes (a partial implementation): export class BaseOpCode implements IOpCode { private _execute: (cpu: ICpu) => void = cpu => { throw new Error( 'Not implemented!' ); } constructor( public name: string , public value : OpCodeValue, public mode: AddressingModes, public size: Byte, logic: (cpu: ICpu) => void ) { this ._execute = logic; } public execute ( cpu: ICpu ): void { this ._execute(cpu); } } And then each op code can inherit and override behavior explicit to that operation: export class InvalidOpCode extends BaseOpCode { constructor (public value: OpCodeValue) { super (INVALID, value, AddressingModes.Single, 0x01 , cpu => { }); } } The interface makes it possible for me to test higher order functions with my own stub or mock object to take the place of a "real" op code. The tests can interact using the interface without concern for how the implementation happens. Interface: signature. "It should look like this and implement these things." Class: implementation. "It is an instance that does these things." Hope that helps!

The biggest lessons programming taught me are that thoughts are creative and we can change our mind. The first is simple. Although science has come a long way in mapping the brain, no one can predict the next thought or "where a thought comes from." Groups are predictive, but individuals are not. I truly believe that thought is is a creative process we should embrace. It is there in code, when we use our thoughts to take ideas and manifest them through code. But it also means we can apply this to other areas in life. Everyone has an inner dialog and most people just let it play out. You end up with habits and "ritual thoughts" that play on auto-drive. Taking some time to be conscious of what you're thinking and create the right thoughts is a powerful experience. That's really the basis of "change your mind." I used to have a lot of negative/what-if thoughts and assumed I was destined to be depressed and pessimistic. This journey taught me I'm in control and the easy way out is to let thoughts take a downward spiral every time something negative comes up. I've learned just like a computer we can reprogram ourselves and break the cycle. I live a much more positive, happy, fulfilled life as a result. I don't waste time with "what if" or negative thoughts and instead embrace the moment. This helps me be more productive with programming, writing, training, and all of my life pursuits. Jeremy

Because it's not multi-tenant (I'm the main consumer) it's just locked with a password I send over SSL. If I were to do authentication, I'd use either Azure AD B2C or Auth0.

I think writing emulators is a great way to learn new languages and frameworks. Because I started my "serious development" on a Commodore 64, I've always been fascinated with the 6502 chipset. It's an 8-bit chip set with only 256 combinations of op codes to learn, with well-defined registers and indexing modes. One of the projects I had the most fun doing was emulating the chip set using Angular and TypeScript: https://github.com/JeremyLikness/6502emulator The project features an emulator, a UI, a compiler, disassembly, a debugger, some sample programs and 6502 test programs. Check it out!

If you're measuring a development job in terms of hours worked, you're doing it wrong. There are too many factors involved in a typical day of work for that to be a meaningful measure. 40 hour is a limit established by the Fair Labor Standards Act that assures overtime. Outside of that, it really doesn't have much meaningful context. Personally I think the 40 hour week (8 hour day) is fine, the bigger question is what you may or may not do beyond those 8 hours per day and how you break them up. As a manager, I learned to value productivity over activity early in my career. I'm much more a fan of working smarter than harder. It's a quality many people admire, "Look how hard he/she works" but I'm not sure that applies to every job. Some jobs are more productive when you work harder, but in development there is definitely an exponential return on investment for working smarter. Simply things like leveraging short cuts, snippets, using frameworks, learning how to troubleshoot quickly and effectively, following practices like TDD that uncover defects early in the process, all can lead to more productivity. Personally I think when people start mandating 50 hours, 60, etc. what most developers end up doing is pacing themselves or finding other things to fill the time without necessarily increasing their productivity. I've measured this on many projects and the solution is almost never to work more hours or add more people. Sure, there are sometimes "crunch times" where it makes sense but a lot of times finding the root cause for delays can be traced back to poor requirements, lack of testing, and bad technology choices. So ... do I think 8 hours is too much? Not really, but I also think it's a meaningless measure for software productivity.

Be pragmatic. It is easy to get caught up in the idea of writing elegant/brilliant/perfect code. You can golf code down to a high performing, low footprint ball of random symbols that no one else can decipher and that's fun ... for a novelty site. As developers, I think we often forget that at the end of the day this isn't about pleasing us or making our code look the best, but rather solving a problem and creating an enduring solution. We want software that works, that doesn't have defects, and is easy to maintain. This means trade-offs. Optimizing a routine to shave off 9 milliseconds when it is part of a UI and the average user takes hundreds of milliseconds even to process and respond is probably a waste of time. Often we'll see a framework touted as "100 times" faster and switch even though it's 10x harder to work with. What do you gain? An imperceptible change in performance for higher cost and longer production cycles. I was on another thread when someone made the blanket declaration "if statements are always a design flaw." Of course, instead of actually explaining why, they continue to maintain they didn't have to explain because it's just a fundamental rule of pure design and using them is wrong. I know it may sound rude, but my hard lesson to learn was "so what." Personally, I know no matter what level of developer is touching my code, this: if (a > b) { x = 'yes' ; } else { x = 'no' ; } Is far more readable and easier to debug and maintain than this: x = a > b ? 'yes' : 'no' ; I may revel in the conciseness of my brilliant code, but what happens when I also have to set y? You could do this: x = a > b ? (y = 1 , 'yes' ) : 'no' ; But what are you really gaining? I would posit not much. You don't need to compact your code, there are tools that do that for you. Why not make it easier to read and add space to add other logic in the branch? The same goes with frameworks. I'll hear "that framework adds so much overhead." But if the overhead isn't visible to the end user and gives my developers the ability to generate stable code 4x faster, why wouldn't I use it? That was a hard lesson to learn because I focused early on my career on being elegant, perfect, and "right." And I produced code that I could brag about and, guess what, a lot of people came along and struggled to maintain. I could get on a soapbox and call them "novices" or I could admit that I was programming for the wrong person: me, instead of the business. Please, learn to be pragmatic.

I have a link shortening utility. A serverless endpoint serves a SPA app (just an HTML asset with embedded JavaScript that loads a framework from the CDN) that lets me past long URLs, enter metadata, and click to generate. There is an Azure Function that takes the long URL and returns a short URL, and another that takes a short link and redirects back to the long link. I also store information about clicks in an Azure Cosmos DB instance and have a PowerBI dashboard for analytics. This lets me run the entire utility (that receives a few thousand clicks per day) for under $1/month. The database and analytics are a little more but that's a fully managed portion of the architecture, rather than serverless.

We have several documents that discuss the pattern and sample implementations. https://docs.microsoft.com/azure/architecture/patterns/cqrs?WT.mc_id=dotnetama-hashnode-jeliknes (CQRS) https://docs.microsoft.com/azure/architecture/patterns/event-sourcing?WT.mc_id=dotnetama-hashnode-jeliknes (Event Sourcing) https://docs.microsoft.com/azure/architecture/guide/architecture-styles/cqrs?WT.mc_id=dotnetama-hashnode-jeliknes (Architecture Style) https://docs.microsoft.com/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/apply-simplified-microservice-cqrs-ddd-patterns?WT.mc_id=dotnetama-hashnode-jeliknes (Microservices) This is also a personal favorite article that talks about its implementation serverless with Azure Cosmos DB: https://medium.com/@richard.j.gobbett/serverless-cqrs-in-azure-p1-e0f2c423f071 Hope those help you get started!