Hello, World!
Inspired by PirateSoftware and https://develop.games/
What is this place?
This site is just a compendium of information for people looking to get into business programming and software development. This site is not a complete resource, but offers jump-off points for a variety of project interests and needs. If this site does not cover your specific need, the information found here may be adjacent to that need. Regardless, if this is the start of your programming journey, you will likely be able to get your boots on the ground with information found here.
Thanks for reading, I hope this helps!
Worth mentioning: There are a ton of resources and links scattered throughout this site to external tools and resources that I’ve used, referenced, and leveraged. I’m not affiliated with any of these resources in any way, save for my use of their documentation and tooling throughout the years.
I want to
Who is Articulous?
Hi there, my name is Steven and I’ve been a software engineer and architect for over a decade. I’ve worked with C#, VB .NET, Java, Kotlin, Flutter, JavaScript, jQuery, Python, PHP, PowerShell, MySQL, SQL, NoSQL, SQLite, and many more languages, frameworks, scripting tools, and platforms. My entire career has been spent developing software for small businesses all the way to enterprise organizations mainly in manufacturing and fintech for B2C and B2B focuses. Server-side, client-side, mobile, API and database only applications have all made appearances throughout the applications I’ve designed, built, deployed, and maintained.
I’ve also worked in Development Operations (DevOps) to stand up Continuous Integration/Continuous Deployment (CI/CD) workflows, standards, and documentation systems to mature codebases. Because of the efforts I’ve put in, I’ve spent years working with the everyday coders, architects, tech leads, and C-suite executives.
With all of this in mind, I’ve built up a decent amount of knowledge, and while I don’t claim to know everything, I have a solid command of the information systems space and the technologies therein. If I don’t know about it, I can at least point people in the right direction.
Where do I start?
- Who is going to be using this tool?
- How will the user(s) access this tool (Web, Windows, Linux, Mac, Smartphone)?
- Is this going to be on-device only, or does it need to access the web?
- Does this tool need to store data?
Core Decisions
A Quick Note about there only being these options on the site. There are many other technologies that you can approach here as well, these are simply the big three that give you the most translatable to other works and have the best documentation/communities for help. There are a plethora of options in any development product, many of which I’ve never heard, so this is only a jump-off point, but half the battle is knowing what you can do so you can go investigate it.
A Quick Note about front end development: If you can, search for support for Bootstrap, which is a boilerplate front-end styling tool that pre-bakes most of the styling you will need to spin up a solid, industry-standard, friendly user interface without needing to know much about CSS (Cascading Style Sheets). It’s worth your time to get to know this platform because it’s used heavily in the industry
Disclaimer: This list is ever-growing and updating, and will never be complete by any means. These are some primaries to get started, so if a language you were anticipating to be on this list isn’t here, that doesn’t make it invalid, a bad option, or otherwise, just that I didn’t think of it, know about it, or forgot about it. Ultimately, the language and frameworks used to develop your application just have to get the job done for your use case.
Often, anymore, software applications are written for web users. In this, you have a slew of options, which can be a bit dizzying. .NET (Microsoft/Windows) offers ASP .NET, the industry choice is React/Angular, but you can also use PHP. Personally, I rarely recommend PHP, though if your focus is on developing WordPress or WordPress Plugins you’ll need to learn to work with PHP to some degree.
Platforms (Web)
PHP is an older technology that was once a paragon of web development. It was the defacto tooling for server-side web development, and, to a degree, front-end development. While PHP is still completely viable, and free (so are the other two tools I mentioned) with downloadable server setups like XAMPP or WAMPP, the language doesn’t have the same standards that more modern languages do. This can affect your cross-language learning or development pace, so consider it carefully. Explore your other options before jumping into PHP specifically. If PHP fits your need, you can start reading their documentation here.
Flutter is relatively new on the scene, and a powerful entry, at that. It’s a framework that enforces a tight coding style using the Dart coding language with modern SOLID standards and dataflows, which makes it consistent and scalable. This is another entry that I have minimal experience with, and the learning curve isn’t terrible. If you’re going into development for the first time and looking to develop an app that’s a single code base for web and mobile, Flutter is worth a look. Beware, however, as anytime there’s a framework that does double duty like this, there’s complexity involved that can make error-chasing a commonality with less-than-helpful error messages and stack traces. If you’re still keen on Flutter, take a look here.
Platforms (Desktop/Server)
If you thought your options for web were significant, desktop/server is even more-so. Desktop and server environments can often have more power in the CPU, memory, and GPU, which allows more parallel processes, graphically intensive drawing, many concurrent connections, and much more. Because of this added potential (your mileage may vary based on what computer you’re developing against), the languages can afford more wiggle room. Worth noting, this section may be more language heavy than framework heavy due to how much versatility these more powerful systems imbue.
Flutter, once again, is a multi-deployment framework for the Dart language that allows you to develop a web and mobile tool in a single code base. This has some downfalls, some upticks, and some quirkiness. You can read more about Flutter in the web section above, but for convenience, just click here.
Tech is always changing...
Platforms (Mobile)
Mobile development has significantly fewer options to choose from. The development process can be very different from what you would experience in developing web and desktop/server applications, which can mean a bit of a learning curve if you’re experienced with non-mobile development at all. Here are a few of the options that you can choose from to start developing apps and mobile-friendly experiences.
With great power...
Mobile apps are lightweight, yet somehow powerful, building data access directly into our pockets. Because of this, however, if you’re not careful, your app may suffer performance issues, difficult-to-diagnose exceptions, or total crashes. Pay attention to your code flows and layouts because they directly affect the user.
Please remember that the languages and frameworks that are listed in these sections are by no means the entire list, and that there are constantly new technologies emerging to better solve the problems that developers face on a regular basis. These are just some of the more popular or recognized tools that are used as of the writing of this page. I’ll do my best to update and adjust as I can, but for the purposes of getting started, these will lead you in the right direction for learning, getting started, and hopefully getting you to a place where you’re more confident trying to develop systems on your own or with a team!
Storage
When you approach question #4, there are a ton of different directions to go in. More often than not, an app will need to store some kind of data. This can be user preferences, system information, translation values, colors, etc. If your app doesn’t need any of this kind of storage, you can skip this section. If you think you may want to store data at some point, give this section a read and keep its points in mind as you design your system(s). Retrofitting storage into a pre-existing app can be painful, so getting a head start on it early in development can prevent some serious stress and headaches.
Databases
SQLite – A free, lightweight, and relational database engine that uses similar syntax to other SQL systems. The entirety of the data can be found in a single file, which can be deleted to remove the database as a whole.
MySQL – A free relational database engine provided by Oracle that uses a similar syntax to other SQL systems. Not as lightweight as SQLite as it requires installation, but much more powerful. MySQL databases cannot be deleted just by deleting a single file like with SQLite, which allows for persistent and robust data for any number of uses. This is often the choice for web service providers because it’s free and more lightweight than competitors like Microsoft SQL Server.
SQL Server (Microsoft) – A paid relational database engine that has a robust setup and installation process, allowing you to fully customize how your databases and their supporting systems are configured. SQL Server is resource intensive, so it’s not recommended for same-system installation in many cases, nor for underpowered hardware like a Pentium Core processor-based machine. This engine can also be quite expensive depending on the scaling necessary or if it’s going to be hosted in the cloud. Microsoft does offer a free version, though it’s limited in its performance and storage capacity until paid for. Consider this engine if you’re building a medium to enterprise sized application that needs to scale and handle incredible amounts of data.
PostgreSQL – PostgreSQL is an open-source relational database engine that offers much of the same extensibility and robustness that SQL Server does, but at the low low cost of free. As you can probably imagine, PostgreSQL is a preferred engine for businesses that are attempting to keep costs low or to modernize from non-SQL based databases. The major drawback of PostgreSQL is that it can suffer from performance issues when write actions are performed at scale, but this can be largely mitigated through intentional design.
MariaDB – This is a fork of the MySQL database engine made by the original developers of MySQL prior to the acquisition of MySQL by Oracle. This is an open-source database engine released under the GPL license, which allows anyone to use it without needing to pay for the engine itself.
Redis – This is an in-memory data store, which allows for fast, low-latency data consumption and streaming. It’s often a preferred system for building online games, data analytics software, and similar where the data is relatively uncomplicated and speed is the primary focus. Complex querying (data fetching) isn’t supported in Redis, meaning that tooling must be built to handle larger sets of data from the outset.
NoSQL (Mongo, Couchbase, CouchDB) – NoSQL is a larger topic than I can fully get into here, but it approaches data storage in a way that is not relational. It stores all data relevant to an object as a document “snapshot” which can be queried (or “fetched”) through filters rather than by ID or aggregate ID. This technical jargon means, essentially, that you don’t need to go searching across an entire database for a single snapshot of a record, you can just look for the document based on the information you know about it. This is great for applications that handle financial documents, need historical data to be untouched, and/or do not have systems that require frequent manipulation of data.
Blockchain – A blockchain database is like a digital notebook that keeps a permanent, unchangeable record of data exchanges. Imagine it as a chain where each block is a page of this notebook, recording information securely and linking to the previous page, making it hard to alter past entries. A practical non-cryptocurrency use of blockchain is in tracking the origins and history of products in supply chains. This ensures that every step, from production to delivery, is transparent and recorded, preventing fraud and verifying authenticity. This technology is fairly “hyped” in modern media due to cryptocurrency, but its uses span further than that; however, some game development studios have talked about its use in their latest games, which, depending on how its used, may be more complicated and detrimental than not.
Files
File storage is not often optimal for large data stores, but can be very useful when looking to hold onto default preferences, small pieces of user information that are non-pertinent, or other volatile needs.
XML – This stands for Extensible Markup Language which is written very similarly to HTML (which is used to develop web page structures). XML is a powerful and customizable standard for data storage and can often be found in use by older APIs for data transfer, Android manifests for a variety of application settings, and even in dynamically generated documents generated by tools like SAP Crystal Reports. XML stores information as plain text, so unless the file itself is encrypted, the text is plainly visible to anyone who opens it in a common text editor. XML makes use of “element tags” which delimit what the data is intended for. For instance, a receipt stored as XML might look like this:
<Header>
<CustomerName>John Doe</CustomerName>
<CustomerPhone>(231) 456-7890</CustomerPhone>
</Header>
<OrderItems>
<OrderItem>
<OrderItemName>T-Shirt</OrderItemName>
<OrderItemQuantity>5</OrderItemQuantity>
<OrderItemPrice>15.99</OrderItemPrice>
</OrderItem>
</OrderItems>
<ReceiptTotals>
<ReceiptSubtotal>79.95</ReceiptSubtotal>
<ReceiptTaxAmount>4.80</ReceiptTaxAmount>
<ReceiptTotal>84.75</ReceiptTotal>
</ReceiptTotals>
</Receipt>
JSON – This stands for JavaScript Object Notation. Much like XML, JSON (often pronounced as JAY-SAHN) is a powerful and extensible notation for storing data and transferring it as text. Instead of using element “tags” JSON uses a bracket and key-value-pair syntax to enable readability and parsing. The same receipt example from the XML section would look like this in JSON:
“Receipt“: {
“Header“: {
“CustomerName“: “John Doe”,
“CustomerPhone“: “(231) 456-7890”
},
“OrderItems“: {
“OrderItem“: {
“OrderItemName“: “T-Shirt”,
“OrderItemQuantity“: “5”,
“OrderItemPrice“: “15.99”
}
},
“ReceiptTotals“: {
“ReceiptSubtotal“: “79.95”,
“ReceiptTaxAmount“: “4.80”,
“ReceiptTotal“: “84.75”
}
}
}
“John Doe”,”(231) 456-7890″,”T-Shirt”,”5″,”15.99″,”79.95″,”4.80″,”84.75″
Memory
Memory storage refers to keeping information in a dedicated “bucket” in the memory chips installed in the computer. In programming this is done by making “variables” that, much like math variables, are just placeholders/aliases for data you care about. In Object Oriented Programming languages like C, C++, Java, C#, JavaScript, Python, etc. an “object” can be defined with multiple properties to logistically store data in memory. Be careful using memory storage because once the application is closed, the data will be lost. This is known as “volatile” storage because the data is not persistent unless written to a storage disk (a hard drive). It’s worth noting that for in-memory storage, often the Singleton Design Pattern will be used so that the object is always the same across the use of the application. This is not always the case as all objects in OOP are technically stored in-memory, but the Singleton Pattern can help centralize this data throughout the lifetime of the application. An example of an object storing data in-memory is provided below in C#:
public class Receipt
{
public string CustomerName = “”;
public string CustomerPhone = “”;
public List<OrderItem> OrderItems = new List<OrderItem>();
public decimal Subtotal = 0.00m;
public decimal TaxAmount = 0.00m;
public decimal Total = 0.00m;
}
public class OrderItem
{
public string Name = “”;
public int Quantity = “”;
public decimal Price = 0.00m;
}
public class Program
{
static void Main(string[] args)
{
var receipt = new Receipt()
{
CustomerName = “John Doe”,
CustomerPhone = “(123) 456-7890”,
OrderItems = new List<OrderItem>()
{
Name = “T-Shirt”,
Quantity = 5,
Price = 15.99
},
Subtotal = 79.95,
TaxAmount = 4.82,
Total = 84.75
};
}
}
In Python, the same code would look something like this:
class Receipt:
def __init__(self):
self.CustomerName = “”
self.CustomerPhone = “”
self.OrderItems = []
self.Subtotal = 0.00
self.TaxAmount = 0.00
self.Total = 0.00
class OrderItem:
def __init__(self):
self.Name = “”
self.Quantity = 0
self.Price = 0.00
if __name__ == “__main__”:
receipt = Receipt()
receipt.CustomerName = “John Doe”
receipt.CustomerPhone = “(123) 456-7890”
receipt.OrderItems.append(OrderItem())
receipt.OrderItems[0].Name = “T-Shirt”
receipt.OrderItems[0].Quantity = 5
receipt.OrderItems[0].Price = 15.99
receipt.Subtotal = 79.95
receipt.TaxAmount = 4.82
receipt.Total = 84.75
Once again, the technologies listed in the storage section are just a jump-off point, and while it covers the most popular storage technologies, there are many considerations and options out there to solve any number of problems. Feel free to take this knowledge and find the right storage option(s) for your use-case. Also note that many of these technologies can be combined into hybrid storage mechanisms to solve for the deficiencies any of the individual storage options may exhibit. We’ll talk more about smart storage practices in the API section.
APIs
APIs allow you to expose whatever data you want without needing to handle port forwarding, network security, or other barriers. Granted, in order to allow an API out from your network, you’ll do that internally, but once the API is accessible by one client outside of your network, it’s accessible by any number of devices. The alternative requires setup from every device.
The right way to store data
The title here is a bit misleading. In order to store data, you will still need a database of some kind. An API is just a gateway that allows apps from a bunch of different devices to access whatever data you want to expose to them.
There are many different ways to create an API based on language and feature set you want. Firstly, what is an API? Earlier I mentioned that an API is a “gateway” and that data can be exposed through it, but how?
In the design section, we’ll talk about code structures, proper separation of concerns, and server-side/client-side relationships, but for now, just know that in many applications, you’ll have a server-side that houses your data (and website if it’s a web app) and a client-side where users typically interact with your system.
On the server-side, you’ll need a series of queries against your database, then code that calls those queries and allows the client-side to “ask questions” of your server through the API. The clients often ask those questions through HTTP Methods which are basically just TSA Lanes at an airport that search and direct traffic. The common HTTP Methods are GET, POST, PUT, and DELETE, though there are some niche others that may suit your needs better (a more comprehensive list is provided by MDN here). The common methods are also often referred to as CRUD operations, which stands for Create, Read, Update, Delete. These are the most basic data interactions that applications need to be considered “feature complete” and relatively self-sustaining.
So an API is just a few HTTP Methods that accept a request (or “question”) from the client, then direct that request to the right database query/queries. Then the queries kick back data, the HTTP Methods format it properly, then send it back to the client for consumption.
But just like any other concept in programming, there are a ton of ways to do it. So what are your options? The next section will lay out some of the common choices and considerations.
API considerations
You’ll probably build something similar to a REST or RESTful API, but the TL;DR version of the following sections is as follows:
REST API: Best for simple, stateless CRUD operations.
SOAP API: Best for enterprise-level, secure, and complex transactions.
GraphQL API: Best for scenarios where clients need precise data and can benefit from a flexible query language.
JSON-RPC/XML-RPC: Best for simple, straightforward RPC operations.
WebSocket API: Best for real-time, bidirectional communication.
OData: Best for standardizing queries and updates across different data sources.
gRPC: Best for high-performance, multi-language environments.
HATEOAS: Best for APIs that require self-discovery and navigable links.
SPARQL: Best for querying RDF and linked data.
REST (Representational State Transfer) API
- Architecture: REST is an architectural style that uses HTTP requests to perform CRUD (Create, Read, Update, Delete) operations.
- Data Format: Typically JSON or XML.
- Features: Stateless, scalable, and uses standard HTTP methods (GET, POST, PUT, DELETE).
- Examples: GitHub API, Twitter API.
Representational State Transfer is a web service architectural style that uses HTTP for communication. REST APIs are highly scalable, stateless, and use standard HTTP methods like GET, POST, PUT, and DELETE. They often use JSON as the data format, which is lightweight and easy to parse. REST is currently the most popular API standard because of its simplicity and efficiency, making it suitable for a wide range of applications from simple web apps to complex microservices architectures.
GraphQL API
- Query Language: GraphQL is a query language for APIs and a runtime for executing those queries.
- Data Format: Typically JSON.
- Features: Clients can request exactly the data they need, multiple resources can be fetched in a single request, strongly typed schema.
- Examples: GitHub GraphQL API, Shopify API.
GraphQL is a query language for APIs and a runtime for executing those queries. It allows clients to request exactly the data they need, which can reduce the number of network requests and amount of data transferred. GraphQL APIs provide a more flexible and efficient alternative to REST by enabling clients to specify their data requirements in a single request. This makes it particularly useful for applications with complex data models and relationships, such as social networks or e-commerce platforms.
JSON-RPC (Remote Procedure Call) API
- Protocol: JSON-RPC is a remote procedure call (RPC) protocol encoded in JSON.
- Data Format: JSON.
- Features: Simple, lightweight, methods are called and responses are returned in JSON.
- Examples: Bitcoin JSON-RPC API.
JSON-RPC is a remote procedure call protocol encoded in JSON. It allows for straightforward and lightweight communication between a client and a server. JSON-RPC is stateless and uses simple JSON messages to request and respond to method calls. This simplicity makes it easy to implement and understand, but it lacks some of the advanced features and flexibility of more modern APIs like REST and GraphQL. JSON-RPC is suitable for applications that require quick and easy integration with minimal overhead.
XML-RPC (Remote Procedure Call) API
- Protocol: XML-RPC is a remote procedure call (RPC) protocol encoded in XML.
- Data Format: XML.
- Features: Simple, uses HTTP for transport, allows remote calls to be made over a network.
- Examples: WordPress XML-RPC API.
XML-RPC is a protocol for making remote procedure calls using XML to encode the calls and HTTP as a transport mechanism. Similar to JSON-RPC, XML-RPC is simple and easy to use, but it relies on XML, which can be verbose and complex to parse. Despite its age, XML-RPC is still used in some legacy systems and applications where XML is the preferred data format. It is less common in modern development due to the rise of JSON-based alternatives.
WebSocket API
- Protocol: WebSocket is a protocol for full-duplex communication channels over a single TCP connection.
- Data Format: Typically JSON or plain text.
- Features: Real-time, bidirectional communication, efficient for live updates (e.g., chat applications, live feeds).
- Examples: Slack API, real-time trading platforms.
WebSocket is a communication protocol that provides full-duplex communication channels over a single TCP connection. Unlike HTTP, which is request-response based, WebSocket allows for real-time, bidirectional communication between a client and a server. This makes it ideal for applications that require live updates, such as chat applications, real-time gaming, and live data feeds. WebSocket can significantly reduce latency and improve performance for these use cases.
OData (Open Data Protocol) API
- Protocol: OData is a protocol for building and consuming RESTful APIs.
- Data Format: Typically JSON or XML.
- Features: Standardizes the way to query and update data, supports CRUD operations.
- Examples: Microsoft Graph API, SAP OData services.
OData is a protocol for building and consuming RESTful APIs. It standardizes CRUD operations and querying capabilities, making it easier to interact with various data sources. OData supports both JSON and XML formats and provides features like filtering, sorting, and paging out of the box. This makes it a good choice for enterprise applications that require a standardized way to expose and consume data. However, its complexity and verbosity may be overkill for simpler applications.
gRPC (gRPC Remote Procedure Calls) API
- Protocol: gRPC is a high-performance RPC framework.
- Data Format: Protocol Buffers (binary format).
- Features: Supports multiple languages, efficient, supports streaming, uses HTTP/2.
- Examples: Google Cloud APIs, Kubernetes API.
gRPC is a high-performance, open-source framework for remote procedure calls. It uses HTTP/2 for transport, Protocol Buffers (a binary serialization format) for data serialization, and supports multiple languages. gRPC is highly efficient and well-suited for microservices architectures where performance and scalability are critical. Its strong typing and contract-based design provide robust API definitions, making it ideal for large-scale distributed systems.
HATEOAS (Hypermedia as the Engine of Application State) API
- Architecture: Part of the REST application architecture.
- Data Format: Typically JSON or XML.
- Features: Uses hypermedia (hyperlinks) to navigate the API, self-descriptive messages.
- Examples: HAL (Hypertext Application Language), JSON API.
HATEOAS is a constraint of the REST application architecture that allows the client to dynamically navigate the API by using hypermedia links provided in the responses. This makes the API more self-descriptive and easier to evolve without breaking client applications. HATEOAS is particularly useful for complex APIs where the client needs to discover and navigate resources dynamically. However, implementing and consuming HATEOAS can be more complex than simpler RESTful approaches.
SPARQL Protocol and RDF Query Language API
- Query Language: SPARQL is a query language for databases, able to retrieve and manipulate data stored in Resource Description Framework (RDF) format.
- Data Format: RDF/XML, Turtle, N-Triples, JSON-LD.
- Features: Used for querying linked data or semantic web data.
- Examples: DBpedia API, Wikidata API.
SPARQL is a query language and protocol used for querying and manipulating data stored in Resource Description Framework (RDF) format. It is widely used in the semantic web and linked data applications. SPARQL allows for complex queries over diverse data sources, making it powerful for applications that need to integrate and analyze large amounts of structured data. However, its use is largely limited to niche applications involving RDF data.
Like previously said, you’ll probably start out with RESTful APIs, but you may find that gRPC is your better bet as you get more familiar with data transfers and interfaces. If your API is going to be internal only, that is, only people within your organization are going to use it, or your app leverages sub-processes (base app launches another app sort of thing), gRPCs are a great way to achieve robust, fast, and customizable inter-process communication. Both REST and gRPC can be used to build plugins for your application or let your customers/clients/users build extensions to the app for their own benefit and workflows. Consider an API at all times when you start a new program or sub-program as it can make customer buy-in that much stronger. It’s also worth noting that solid documentation of an API can be the difference between a great adoption of your app and total spurning of it. Also note that most consumer-available applications have an API or some sort of client-extensible tooling available. To stay competitive, if you’re releasing this app, you’ll likely want this as a bon to adopting your program.