The differences in development reside mostly in the initial architecting of the product. When considering cloud technologies, it's important to decide whether you're looking to develop a traditional monolithic application, a set of microservices, or whether you'll forgo that entirely and go with a serverless architecture.

Monolithic applications are what you could consider the "default" architecture. All your services and all your application logic runs through a single, monolithic, application. Monolithic applications are the simplest to conceptualize, maintain, and develop. They do not require shared data contracts or an inter-process communication layer. They will, however, have a larger footprint and require larger hardware requirements as everything is hosted in a single place. This can often lead to higher costs when deploying to the cloud. Additionally, monolithic applications introduce single points of failure that could take entire services offline should errant code be introduced (Kharenko, 2015.)

Microservices, as the name implies, involve designing your application as a set of pseudo-independent services that share data contracts and often an inter-process communication layer such as RabbitMQ or Kafka. Each individual microservice endeavors to remain small, compact, and quick. Breaking up your services in this fashion allows your infrastructure management software (often Kubernetes) to selectively scale individual portions of your application, leading to an overall reduction in cost and footprint as the application scales to meet growing customer demand (Kharenko, 2015.)

Serverless architecture is the idea of taking microservices to their extreme logical conclusion. Instead of developing applications, the developers endeavor to encapsulate all functionality into independent autonomous functions that rely completely on the cloud provider's interface (What Is Serverless Architecture?, n.d.) The benefit to this is that you would no longer be building a traditional application that needs to be managed, configured, and hosted on the cloud. Hosting, management, and scaling are all handled at the cloud provider level. Some drawbacks to this method include: existing applications must be completely re-written and re-designed to work as serverless, generally an internet connection is required at all times during development, not an intuitive way to build applications leading to longer development times and developer dissatisfaction.

I slightly touched on the cost of architecting for the cloud. Putting a serverless architecture aside, deploying microservices or a monolithic application in the cloud vs a traditional in-house deployment can save significant costs -- depending on the organization and application.

A large web application designed to be served to multiple regions would likely save a lot of money going with a pre-built cloud solution such as AWS which already has servers set up in multiple regions. The costs savings being equipment, network engineers, and land.

However, a smaller application meant to serve a single local development studio or office would save considerable amounts of money long-term investing in a single server and hosting it on-premises. While the upfront cost of the server and a network engineer to set it up would be higher (I'd estimate $5-10000 assuming you're paying professionals and getting a half-decent server), the ongoing costs plummet to the cost of electricity and, should an internet outage occur, the local office would still have access to its core systems (Hughes, 2018.)

I believe the question: "Do today's cloud-based platforms make traditional operating systems obsolete? Why or why not?" is self-evident through my previous responses. No, cloud-based platforms do not make traditional operating systems obsolete because cloud platforms rely on traditional operating systems to serve their content. The question has never been (and likely will never be) "Cloud vs Traditional Operating Systems" -- this implies a fundamental misunderstanding of what the Cloud is. The real question is one of deployment: "Cloud vs On-Prem" or "Cloud vs Self-Hosted" is a lot closer to the core concern we, as engineers, need to concern ourselves with.

If I were to develop "prototype" code, I would not concern myself with which operating system it's designed to run on. I'd choose a trivially cross-platform technology that is well-suited to the space and run with it. For web servers, possibly something like Golang for its native binaries and cross-compilation. For graphics applications, I'd either use a cross-platform game engine or a cross-platform graphics API such as Vulkan or OpenGL. I don't like the question. Answering it directly though, assuming my prototype is meant to be run as a server somewhere, I would ensure it runs on Linux as Linux, and Linux Containers power most of the servers on the internet.

- Paul

References

What is Serverless Architecture? (n.d.). Www.twilio.com. https://www.twilio.com/docs/glossary/what-is-serverless-architecture

Hughes, A. (2018). Blog: On Premise vs. Cloud: Key Differences, Benefits and Risks | Cleo. Cleo. https://www.cleo.com/blog/knowledge-base-on-premise-vs-cloud

Kharenko, A. (2015, October 9). Monolithic vs. Microservices Architecture. Medium; Microservices Practitioner Articles. https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59

this week I decided to take a closer look at the role of the Development Team in relation to scrum activities due to my having possibly unpopular opinions about the other two roles that would likely color my response in a way that is unproductive to this discussion.

As I have more experience as part of a Development Team than any other, I feel that I could share my thoughts on what has made colleagues a pleasure to be on a team with.

The trait that I found most important to a member of the development team is that of "Criticizes ideas, not people." Taken one step further, it is important for members of a development team to not take criticisms of their ideas as commentary on their personal abilities (or lack thereof.) Additionally, and I think it is tangentially related, it's important for developers to take ownership of their failures as well as their successes. Not only does it show maturity and leadership qualities but it also helps foster a cooperative environment of trust and respect (Consulting, 2021.)

Taking ownership of your mistakes also enables you to learn from them which enables the next important trait of a good member of a development team: "Pursues technical excellence." Not much needs to be said about the importance of this trait. It is fairly self-evident that having a colleague disinterested in pursuing sound technology will, in the long run, be a detriment to a development team. As they say: "You are only as strong as your weakest link."

Finally, I think the last trait I would mark out as being quite important is that of always having fun with each other. As software developers, especially in large corporate settings, your days can get quite repetitive and dull. You'll likely feel that you're mostly a cog in a wheel and that every day is like the last. At these times, having a development team you genuinely enjoy working with can make the difference between burnout and a long successful career.

Anecdotally, I was working at Cisco on some very dry routing software for several years before we transitioned to working from home at the onset of COVID-19. After the initial year, the work itself was fairly dry but the people I worked with at the office were very intelligent, fun to be around, and didn't take themselves too seriously. After the transition, I found that there was very little communication between ourselves anymore outside of business-centric concerns. It sucked the fun right out of the position and I quickly started to feel burnout. My point is that a fun work environment can make up for a lack of passion for the technology itself.

I've since moved on to work with a team that I can both have fun with remotely, and interests me technologically -- therefore it's always good to re-assess your enjoyment on a regular basis. Software Engineers are in high demand therefore you can nearly always find a position tangential to your preferred field, or technology. This greatly increases job satisfaction and reduces the chance of burnout. Enjoying what you're working on also has the added benefit of increasing the quality of your work as you'll be more engaged and more likely to hit your flow state.

Thanks for reading,

Paul

References

Overeem, B. (2016). Characteristics of a Great Scrum Team. https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-08/Characteristics%20of%20a%20Great%20Scrum%20Team.pdf

Consulting, M. A. P. (2021, March 11). Take Ownership of Your Mistakes. MAP | Management Consulting, Executive Coaching, Leadership Development. https://www.mapconsulting.com/take-ownership-of-your-mistakes/

Performance

C++

Generally considered, alongside C, to be among the most performant languages. This is somewhat of a misconception. While it is true that C++ has the ability to outperform other languages, this performance does not come by default. Those inexperienced with memory management and good programming practices will often write less performant code in C++ than in a more managed language such as Java or C#. That being said, due to C++ compiling down to native assembly code, it is possible to write code in a way to optimize low-level machine instructions. This ability is not available in the other languages being discussed.

Python

The least performant on this list. This is because, and this over-simplified, due to the interpreted nature of Python. When you execute Python code, it is first run through a compiler which converts your code into a Python-specific bytecode that can be run by a Python interpreter, the interpreter then reads this bytecode and converts it once again into machine-specific instructions for the target platform (Dhruvil Karani, 2020.) The compilation step will often cause a delay in initial execution while the interpretation steps come at a somewhat significant (2X-10X slower) performance cost compared to traditionally compile languages.

Java

This is the area where Java is, as much as I hate to admit it, mischaracterized. In its infancy, Java suffered from many of the same issues as we just discussed with Python -- with the main difference being that the compilation step is a separate step before execution. Over the years, however, many of those performance issues have been addressed and optimized away. One example of such optimization is in Java's ability to analyze and optimize application hotspots with the JIT (Just In Time) compiler which will compile frequently accessed Java bytecode as native code throughout runtime to gain native performance in key areas as the application runs (Oaks, 2014.) This is the basis for many people claiming that the JVM needs to "warm up" before being able to properly measure its performance.

Portability

C++

C++ falls high on portability. There's a C++ compiler for pretty much every platform (List of compilers, 2020.) C++ code, however, is not portable by default. Most standard libraries are supported on most compilers -- however specific support can and does vary based on CPU architecture and platform. Additionally, the C++ spec does not provide any cross-platform GUI libraries. One advantage to going with C++ is that for any platform you support, you get native binaries that require no additional software on the system.

Python

Python, being an interpreted language, is highly portable in that the same Python code should have identical output on any platform it runs on. The caveat to this, however, is that it requires a Python interpreter to be available on the machine. Additionally (and anecdotally), some of the supporting tools (pip specifically in this example) will not immediately be compatible with every platform. For example, the numpy package and packages that rely on it are not (as of a couple of months ago), installable on the new Mac M1 machines using pip. While not an issue with Python specifically, this example shows a weakness in its portability. Another disadvantage to Python is that it is much more difficult to get any distributable binaries that don't require a Python interpreter to be pre-installed on the system. I suspect many binaries that would run Python in the background have a thin C++ layer such as we created in this class to distribute.

Java

Java is generally considered the gold standard in terms of portability due to its Java Virtual Machine (JVM). All Java code and libraries are guaranteed to be portable to every platform on which a JVM can be found (Hartman, 2021.) Due to this guarantee, the language's adoption, and the large amounts of money poured into the Java project, a JVM is available for pretty much every platform. Java code is compiled down into Java Byte Code, which requires a JVM on the target machine to run. The benefit is that the same Java Byte Code can be run, without changes, on any JVM.

Supporting Libraries and Ease of Use

C++

The ease of use of a language is closely tied to its supporting libraries and the ease with which they're used. To begin, C++ is a language that has a decently steep learning curve. While easier to get a Hello World application than Java, it takes considerably more effort to accomplish anything "substantial" than more managed languages such as the other ones on this list. Memory management needs to be handled explicitly and consciously. In addition to this, integrating outside libraries is more complicated due to the low-level nature of the language. The build process often requires the importing of multiple libraries, compiling and configuration using a tool such as CMake, and a plethora of other concerns you don't need to deal with in many other languages. Package management is also not defined in the standard either (though this pain point will be less painful with the introduction and support of modules in C++20.) C++ also integrates pretty seamlessly with the wealth of C libraries available which gives it access to a very long history of software development.

Python

Often considered the easiest language to work in. Not only for its more language-natural syntax but also for its robust, built-in, feature set and ecosystem of supporting libraries. Used often as a scripting language to perform quick and simple tasks, it is often combined with native libraries to offset the performance cost of the interpreter. Memory is managed and package management is, essentially, part of the Python standard.

Java

A middle ground between C++ and Python. Many people find Java to be more difficult to get started with due to its large amount of boilerplate to get a simple Hello World application. While the syntax is very C-like, building substantial applications comes with less cognitive overhead considering memory management is handled for you and there are fairly strict guidelines on what is and is not allowed. Package management can be painful as well however Maven is fairly simple to use and has emerged as the defacto standard -- making it relatively easy to figure out due to the number of resources available.

All that being said, I have naturally tended towards using C++ in most of my applications as I am I work on game engines for a living, specifically using the OpenGL, Metal, and Vulkan APIs. These APIs (other than Metal), are provided as C libraries or have a thin C++ abstraction on top of a C library.

Game engines, and games in general, use more memory than most standard applications both on the GPU and CPU. They also have fairly strict performance requirements. Players generally expect games to run at a constant 60 frames per second, or as high as 120 frames per second for a smooth virtual reality experience. This requires carefully managing when data is loaded or unloaded into memory and also requires that the underlying machine code is doing as little as possible. Manual memory management is not possible in most languages and any language with an interpretation layer will not allow you to micromanage specific assembly calls (this is likely an untrue blanket statement but holds as a general rule.)

For the actual gameplay systems implementation, many engines will use a higher-level language such as C# (unity), blueprints (Unreal), GDScript (Godot), or Lua (Roblox and World of Warcraft) and provide a simple interface to the underlying optimized code. If you asked yourself what the point of embedding Python into your application it's largely for these kinds of setups. A setup wherein you provide a simplified, safe API in a higher-level language for interacting with your system while hiding away all the complicated pieces that can break if used wrong.

Programming languages are a fun topic that a lot of people get really passionate about, sometimes in non-productive ways. The key is to understand that every language was created for a purpose and most, looking at you Brainf*ck (Brainfuck, 2021), have use-cases where an argument can be made to be chosen.

Thank you for coming to my TED talk,
Paul

References

List of compilers. (2020, January 9). Wikipedia. https://en.wikipedia.org/wiki/List_of_compilers

Hartman, J. (2021, December 11). Java Virtual Machine (JVM) & its Architecture. Www.guru99.com. https://www.guru99.com/java-virtual-machine-jvm.html

Oaks, S. (2014). 4. Working with the JIT Compiler - Java Performance: The Definitive Guide [Book]. Www.oreilly.com. https://www.oreilly.com/library/view/java-performance-the/9781449363512/ch04.html

Dhruvil Karani. (2020, January 9). How does Python work? Medium; Towards Data Science. https://towardsdatascience.com/how-does-python-work-6f21fd197888

Brainfuck. (2021, October 5). Wikipedia. https://en.wikipedia.org/wiki/Brainfuck

The reason for this is because HR application systems these days nearly universally have some parser binning a large portion of resumes and applications long before a human ever sees them. Don't have a degree? Binned. Missing a keyword? Binned.

Recruiters will often have direct connections with the hiring managers in their area and be able to "put a good word in" for you. I've seen a few people get good results focusing on their LinkedIn profile, reaching out to as many recruiters as possible. Scheduling phone calls or face-to-face conversations is 1000x better than instant messaging.

That being said, you need to impress. Therefore, you should have a strong portfolio or demonstrated experience. You should have a fairly full github profile, with good activity stats. This is what my chart looks like while working a fulltime job and attending university:

If your focus is to find a job, and you're not working, it should likely be a lot more filled up.

As for what you should put in your portfolio, I want to say it barely matters with one caveat: it needs to be somewhat original, not following a tutorial. There are trends hiring managers see with portfolios that make a lot of candidates look the same. For a long time, TODO apps were the fullstack application to put on your resume. I think some youtube videos told people this so like 4/5 new developers had it as their showcase piece. For the last couple of years, COVID tracker apps have dominated. A lot of people have started shifting to that.

Myself, I've had a variety of things I worked on over the years. I built a mario maker clone in a game engine which included a rest api for user management and level storage. I built a fairly substantial container management system that balanaced containers across multiple docker endpoints hosted across different systems. Some C++ client/server applications. I also have a main YouTube channel where I've been on-and-off posting tutorials for the more tricky things I've learned over the years. Whenever I feel that there wasn't a good lesson available and I had to struggle for a few hours, I organize the work and condense the knowledge as succinctly as possible. This is good for your portfolio and helps you retain everything.

In the end, find something meaty that you find interesting and try to build it. Stick it on GitHub and look for the next thing. This will set you up to be able to "unstick" yourself, give you a grasp on some of the larger software engineering concerns around architecture and generally make you less annoying to senior engineers. This may sound harsh, but this is some of the justification for paying junior engineers so much less. They take up a lot more of a senior engineer's time.

Building on that, the final piece of advice I give everyone: never accept a junior/ internship role. It's more beneficial for you to spend 6 months building an impressive portfolio and getting a full position than settling for a junior role at (usually) a massive pay cut with the same professional responsibilities. Your first role in the industry plays a large role in your career's short and longterm trajectory (Don, 2012.) The salary difference between a "junior software engineer" and "software engineer" is usually substantial. Think 50-60k/yr to someone else's 85-100k/yr.

Hope this is useful, sorry for the wall of text. I always have lots to say.

References

Don. (2012, September 26). How Your Starting Salary Affects Your Career Earnings. 20s Finances. https://www.20sfinances.com/how-your-starting-salary-affects-your-career-earnings/

The first principle, inheritance, describes one’s ability to describe data objects in a way that can be extended to create new types while reducing repeated code. This plays well with another programming principle: the DRY principle which states, in its most simple and reduced form: Don’t Repeat Yourself (Don’t Repeat Yourself, n.d.) One of the key advantages to inheritance is that you can hold a collection of objects referenced by their parent classes. There are pitfalls in relying too heavily on inheritance. Heavily subclassed codebases are more difficult to understand, read, and most importantly, unit test. The trick is to inherit the right classes. There’s a simple way of getting a general idea if inheritance may be the right call. Does the proposed subclass describe an “is a” or a “has a” relationship? Let’s use an Animal class. A cat “is an” animal; therefore, inheritance likely makes sense to describe their relationship. However, if the relationship can be described as “has a” (a cat “has a” tail), then it’s better to describe the relationship through composition (Nero, 2020.)

The second principle, encapsulation, describes grouping like items together as a logical whole and limiting access to the internals in order to create atomic objects that aren’t affected by, and do not affect, outside classes. This is seen most commonly by class member variables and are often what is being stored when discussing the aforementioned method of composition.

The third principle, abstraction, is the idea of distilling the essence of an object to its most core component pieces and providing an interface for interacting with those pieces. At the most basic level, it can be described as the verbs that can be performed on, or by, an object. Going back to our Cat example, a cat’s abstraction not only includes its properties (color, size, etc) but also the things it can do (Walk, Run, Meow, Purr, Eat, Hunt) and the things that can be done to it (Pet, Feed, Pick Up).

Finally, the last principle of polymorphism is the idea that classes related by inheritance can implement the same interface with different implementations. Let’s assume we have a Feline parent class with a defined function of Eat. This Eat function can be implemented differently on the Cat class (eats 10lbs of food per day) than on the Tiger class (eats 100lbs of food per day.) This principle is the main enabler to the example of sharing the same container. In a simulation, you can have an array of Felines which, once per iteration, calls its Eat function. This would allow different amounts of food to leave the simulation’s ecosystem based on the type of Feline without having to write duplicate code for each breed.

The most interesting thing that I’ve played with so far in this course is the idea of generics. In the final project, I used generics to create search functions for the various animal types in order to follow the DRY principle. I had used them in the past but had never had a need for creating my own in Java.

Until next time,

Paul

References

Don’t Repeat Yourself. (n.d.). DevIQ. https://deviq.com/principles/dont-repeat-yourself

Nero, R. D. (2020, January 8). Inheritance versus composition: How to choose. InfoWorld. https://www.infoworld.com/article/3409071/java-challenger-7-debugging-java-inheritance.html