Builder design pattern in Elixir

Builder design pattern is traditionally linked with an object oriented programming. In a book "Design Patterns: Elements of Reusable Object-Oriented Software" builder pattern is described by GoF as:

„Separate the construction of a complex object from its representation so that the same construction process can create different representations."

and it's a part of an object creational design patterns.

For Elixir, as a functional programming language, we can define builder pattern as:

„Separate the construction of a complex data structures from its representation so that the same construction process can create different representations."

Some time ago I wrote an article how to apply that pattern to an object oriented language ("Builder design pattern in Ruby"). Now I would like to show you how we can use that construction in Elixir.

Let's define some simple structure that reflects User :

We can build our data like this:

With that approach we have following problems:

adding new fields to the structure will only make the situation worse,

logic how the data is build is hidden in its "instantiation".

To fix that, we can build another module that will have a knowledge on how to build a user. Such a module should allow us to create a user using different plans. It can look like this:

We can use UserBuilder to create a user like this:

So we are using simple functions to build selected part of a user. We can pick different functions to achieve multiple plans. And finally, we can have an algorithm (or logic) how some parts of a user are created, closed in the builder module (login_credentials).

Source: Builder design pattern in Elixir

How to create a Design System in Sketch (Part Two)

Ok, so if you've been following along you will see that we now have our Base Colours, Overlays etc.. in place, and with their Shared Styles (i.e; Fill/Primary) created.

We've also set up our Typography, as well as other various styles such as shadows, gradients etc…

Going back to the Colours, let's now take those saved Shared Styles and create some Symbols which will eventually propagate throughout our Design System.

Let's get to it…

Less talking. More doing. Let's get to it! Colour Symbols

I'll concentrate just on the Primary Colour that we created for this tutorial, otherwise, like I mentioned, this will turn into a 12 hour tutorial, and who's got the time in between projects, xmas shopping and thinking 'Ooh is InVision Studio really all dat?'.

I created a Symbols page myself (yup, it's a unorthodox way of doing things, but honestly it will make sense in the end) and then drew out a Rectangle (100x100) and applied the Fill/Primary Shared Style, then renamed that layer to Base.

I then simply created a new Symbol, and named it Color/Primary.

I removed the original so I was just left with the new Symbol; Color/Primary.

Then it was simply a matter of duplicating that new Symbol, selecting the Base layer, choosing the other Fill Shared Styles I had created previously, and then renaming the Symbol in the Layer List.

With those simple coloured blocks of Symbol joy now in place you can apply them to pretty much any other Symbol with ease.

Text Symbols

But first before we do, let's create some Text Symbols. Yup as it stands this is something that you have to do manually until Sketch creates an amazing update that lets us bypass this rather mundane process. Here's hoping!

I wanted to aim for 2 sets of Text Symbols. One for Buttons and the other for Inputs. Using Font Family #1 (Poppins) for Buttons, and Font Family #2 (Open Sans) for Form Inputs, Labels, Messages and the like.

I chose specific Text Styles I had created previously -

Black

Green

Grey

Light Grey

Primary

Red

White

I then opted for 3 sizes for each of my Text Symbols. Large, Medium and Small. And then broke these down even further into Symbols for Left, Right and Centre aligned text.

Placing a Text Style onto my Symbols page (i.e; H5/Font Family #1/Center/Black/Bold). I then edited the text to read 'Button', and created a Symbol from this (Text/Button/Large/Center/Black).

I then pinned the Text Layer to the left and right edges of the Symbol so it would align correctly when used inside of a Button Symbol (which we'll touch upon later).

Yes, the creation of Text Symbols, and as I came to quickly realise, is the most time-consuming of all when setting up a Design System in Sketch, but having those Symbols in place allows you so much control in the way of Overrides when you're building out the many Symbols that come after (Buttons, Inputs, Menu Items, Notifications, Dropdowns and more).

So by the time I had eventually finished creating the Text Symbols, I had something like the following…

Following a Symbol naming convention of -

Text/Button/Large/Center/Black

Text/Button/Medium/Center/Black

Text/Button/Small/Center/Black

With of course Left/Right alignment and Colour varieties in place also (ie; Text/Button/Large/Left/Green).

I did something very similar for the Input Symbols, opting to use Font Family #1 (Open Sans) for those…

Icon Symbols

With the icons for Cabana I opted for (at least 90% of them) from the Google Material Icon Set. It didn't have enough variety in there, personally, so I had to call upon another Icon Set to fill in the gaps.

Let me show you how I enabled Symbol Overrides for each of the icons used…

I simply created a Rectangle (24x24, which adheres to the 8pt Grid System), which would act as a bounding box for my Icons to aid with alignment and visual consistency going forward.

I placed my Color/Primary Symbol over the top of this, and resized it to the same (24x24)…

I then went ahead and dragged in the relevant Icon (I used the ever reliable IconJar for this), and resized and aligned it accordingly. It was brought in inside of a folder so I took the Shape Layers out of this folder and the deleted the folder (You cannot create Masks with folders I'm afraid).

I then removed the icons Fill from the Inspector Panel, and turned it into a Mask (right-clicking on the icon and selecting Mask), until I had the following…

Then I selected all the elements (Color Symbol, Icon Shape, and Bounding Box Shape), and converted to a Symbol…

I deleted the original until I was left with the fresh Symbol, and then finally selected the Bounding Box Layer and using the Resizing Constraints, pinned it to all sides.

Using the same process as above I went ahead and created all the other Icon Symbols. Oh around 150 give or take! I created them in record time (said in the most sarcastic tone of voice ever). Now I had a wide variety of Icon Symbols that I could bake into other Symbols, with the added bonus of Color Overrides now at my disposal. Oh my Sketch you are all that!

In the 3rd Part of this 4 Part Mini-Series (Does it qualify as a mini-series in 4 parts? Hey ho), I'll show you the creation of the Button Shapes and States, and also the various Input States. Then in the 4th and final part I'll be showing you how to put these itty-bitty Symbols together to build out some fully featured Components. Hurrah!

Don't want to build a Design System yourself? You can pick up a copy of Cabana right here.

Use the offer code MEDIUM25 to receive 25% OFF.

Thanks for reading the article,

Marc

Designer, Author, Father and Lover of Chocolate Digestives

Source: How to create a Design System in Sketch (Part Two)

From domain-driven design to microservices

As many of you may recall, the software design and architecture style known as service-oriented architecture (SOA) emerged in the mid 1990s. Since then, we have discovered better ways to build systems, including advances in cloud-based virtualization, continuous integration and delivery, and microservices. In the process, these technologies have made SOA and all the associated benefits a reality.

In November, I delved into explaining how microservices can be introduced into a large organization with well-established legacy systems. In this post, I cover domain-driven design (DDD) and how this development philosophy can be used to represent the real world in code while being well-suited to a microservices implementation.

Cohesion is an early tenet of software design and refers to the degree of functional relatedness that exists inside a module or class. In this context, cohesion was first described in the late 1970s by Tom DeMarco and has come to mean grouping and keeping together those things that change for the same reasons and separate the functionality that changes for different reasons. 

DDD provides an avenue to facilitate the development of highly cohesive systems through bounded contexts. Microservices is an implementation approach that encourages you to focus your service boundaries on the business domain boundaries. DDD and microservices can be used together as you move your organization to a service-oriented design and reap the benefits of continuous integration and delivery.

The seminal work in DDD was defined in a 2003 book by Eric Evans called Domain-Driven Design: Tackling Complexity in the Heart of Software. The overarching philosophy of DDD is to use the notion of bounded contexts which form protective layers around models that define the business domain. Bounded contexts are analogous to departments in a company—the legal department has certain specific responsibilities (contexts) that are different than the IT department and those responsibilities are enforced by rules (boundaries) for interaction and obtaining services from the departments. 

This is the same for bounded contexts that you model using DDD. To facilitate a common understanding of the problem domain and translate that domain knowledge into a computer system, the business and technical team must develop a common language. In DDD this common language is called the ubiquitous language (UL). As the technical staff develops its models and code, it uses the UL to decrease the risk of misunderstanding between the business analysts and the engineering staff as the project progresses. 

This also serves to provide an additional layer of documentation of the systems and enhances the organization's understanding of how a system was designed and intended to work. The analysis models that are used to understand and define the domain are tied to the code models that are used to create software by the UL.

Other key principles of DDD include:

Iterative creation of the analysis and code models. As the team learns more about the domai, it iterates on its analysis and code models, keeping both in sync. DDD does not specify tools, databases, or languages, but I have used UML (Universal Modeling Language) to create analysis models, and my code or implementation models were done in C++ and Java.

Collaboration of the business and technical teams requires close, face-to-face collaboration to create the relevant models. This is a heavy commitment for all parties to develop the UL, use it to define the domain, iterate through the definition of the domain, and focus on the problem instead of jumping directly to a solution.

Focus on the core domains. The core domains are those domains that will make the product a success. It is a core domain if it is absolutely essential to the success of the business. You should be asking yourselves how this domain increases revenue, cuts costs, or increases efficiency, and why and how this domain is critical to the business.

The problem you are solving must be substantial. There is no use in implementing DDD for problems that are insignificant, won't move the needle for the business, or are better solved with a commercial off-the-shelf solution.

After you have begun to understand the business problem and developed models to define it you will have to think about how to integrate bounded contexts. In their book Enterprise Integration Patterns (Addison Wesley Signature Series), Gregor Hohpe and Bobby Woolf define four integration styles: file transfer, shared database, remote procedure invocation, and messaging. In most applications of substantial size and for reasons of cohesion your DDD and technical team will most likely settle on remote procedure invocation and/or messaging for integration.

From domain-driven design to microservices, pairing these two approaches to solve large and complex problems makes good business sense.

This article is published as part of the IDG Contributor Network. Want to Join?

Source: From domain-driven design to microservices

A low-code User eXperience ‘design language’

Mendix Atlas UI is a low-code tool intended for software application developers who find themselves bereft of any perceptible level of 'front-end' development or UI design skills.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Atlas can be used to define a standardised design language (to promote design best practices) across multiple autonomous development teams — this can help ensure that all apps conform to the organisation's own design principles.

Magical analyst house Gartner has estimated that there may be as few as one User eXperience (UX) designer for every 17 developers, a survey result that Menidx is keen to highlight.

Layered componentised UI

Mendix Atlas is described as a layered componentised UI framework with a web-based modelling tool featuring ready-to-use UI elements.

UIs are constructed through a combination of navigation layouts, page templates, building blocks (pre-configured assemblies of UI components) and widgets. Atlas assembles widgets in pre-configured layouts with optimal proportions, spacing and individual design properties.

The resulting app's visual style automatically reflects a selected visual theme – either one provided by Mendix or a custom theme created with the Theme Customiser.

Enterprise design language

According to Mendix, "All design elements can be packaged as enterprise design language modules and distributed via a private App Store, ensuring that the organisation's UI and design best practices are automatically employed across all Mendix development teams."

The Mendix Web Modeler is meant for developers (and power users) wanting to materialise their app ideas using Atlas design elements.

An integrated Toolbox enables discovery and drag-and-drop consumption of reusable building blocks and widgets. In addition, the Web Modeler bi-directionally syncs with the Desktop Modeler so developers can enhance prototypes with more complex logic and integrations, turning them into production applications.

Source: A low-code User eXperience 'design language'

How website design and development processes integrate with IoT

The internet of things continues to be one of the hottest trends in the technology world these days. The technology has impacted all facets of tech development and, of course, the way that websites are designed and developed.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Web design and the internet of everything

There's no denying the buzz about the internet of things, it is a notion that pretty much everything, from automobiles and refrigerators to industrial machines and environmental sensors to baby monitors and surveillance cameras can be equipped with circuitry, allowing them to connect to the internet, offering information continuously or on-demand. A lot of internet-connected devices are on the market already. In any case, each IoT device has to be accessed, managed, configured and manipulated at some point. Doing so requires a more familiar internet-connected device, like a smartphone or laptop. And this commonly means new web development and design techniques.

Design considerations for IoT interaction

A website design company should be aware and knowledgeable of the different considerations for design and IoT interactions. The following are some design considerations required to let users interact with IoT devices:

Back end: To allow users to interact with IoT devices, a way of establishing communications among them should be established. Since each device has various commands, capabilities and data, it could transmit and receive exactly how to communicate device to device.

User interface: A web-based UI for an IoT app should be clean, fast and intuitive. All the standard usability best practices would be brought to bear when it comes to designing the interface, which include meaningful feedback, good user assistance and logical flow. Keep in mind that many, if not most, usage instances involve mobile devices.

Security and privacy: The downside of IoT is that it presents more opportunities for hackers. If one could unlock a web-connected front door, a hacker potentially could do the same and help himself to the contents of the home. Part of the privacy and security responsibility lies on the device designers, but a third-party web designer has to make security the main design consideration.

Power management: A lot of IoT devices are battery-powered and wireless; excessive back-and-forth communications would prematurely drain the battery. Communications should be designed to minimize power usage.

Speed: Unlike traditional websites, where requests go to a web server that sends back data, there's another communications leg involved between an IoT device and web server. This possibly means more latency and the perception of slow response of users. Thus, design strategies for slow connections must be adopted.

Testing considerations: Testing an IoT website is a bit more complicated than it is for a traditional site.

Many opportunities to make lives easier

The advent of the internet of things presents a lot of opportunities to build innovative, new and useful apps to make people's lives easier. It is good to know that the IoT development landscape is improving, but the present ecosystem still is rampant with difficult-to-use and fragile devices, most of which come with disparate communication protocols and security flaws that prevent seamless integrations. Instead of squeezing embedded C to the web world, there are other web tools and technology that could be used.

Impact of IoT on web design

The growth of IoT already is beginning to exert influence on web design. The following are some considerations for businesses when building websites, as well as web-based user interfaces:

Business sites should develop the growing sophisticated ability of responding to personalized data from web-enabled devices.

With a business site, activities should interact more directly with IoT devices. For example, a surge in search queries or uptick in online purchases for a certain product could impact a machine's activities immediately for both those companies that manufacture products and those that prepare them for distribution. A third-party vendor message on the availability of a new product could automatically and quickly lead to its promotion on the website.

Flexible, clean user interfaces are imperative. Designing websites that look good on screens of various sizes is imperative. IoT has many demands of user interfaces and web design; people will not interact with various devices in the same manner. Rather, they will have different expectations for the information displayed on every device and how they could optimally engage with it. Intelligible icons and minimal text can make the most of small interfaces. There would also be an increase in the need for dashboards, which include apps that help people manage data from various devices.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

Source: How website design and development processes integrate with IoT