BOSTON, Nov. 1, 2023 /PRNewswire/ -- Intevity, a leading digital technology consultancy, has acquired Techabo, a rapidly growing digital consulting agency. The purchase adds momentum to Intevity's focus on strategic growth and brings talented employees on ...

INTEVITY ACQUIRES TECHABO

Nurses are questioning if automation can help alleviate the national nurse shortage and free up their time to attend to patients.

Automation 'has not been kind to nursing' — here's why

Going beyond traditional consulting services, MSP+OS offers a comprehensive, client-centric approach that covers everything from data migration and systems optimization to executive coaching. This initiative empowers technology business leaders to ...

Managed Service Provider and IT Service Industries to Be Reshaped by Five Companies Merging to Form MSP+OS

As health systems continue to deal with workforce shortages, many leaders are turning to technology to try to alleviate some of the burdens on their existing staff. The Guthrie Clinic, based in Sayre, Pa., created a virtual care command center, dubbed the ...

How health systems are using tech to address staff shortages

Identiv, Inc. (NASDAQ: INVE), a global digital security and identification leader in the Internet of Things (IoT), has

Identiv Augments IoT Design and Prototype Capabilities at Engineering Excellence Center in Germany

The University of Connecticut Management Information Systems major was officially restructured this semester to give students a competitive advantage in the workforce and stay aligned with changes in technology and business,

A new name for the management information systems (MIS) major

Companies introduce Siemens Industrial Copilot, a generative AI-powered assistant, designed to enhance human-machine collaboration and boost productivity.Companies will work together to build additional copilots for manufacturing,

Siemens and Microsoft partner to drive cross-industry AI adoption

Home broadband, Wi-Fi speed and reliability guarantees and speed testing/diagnostics were among the most popular services that providers plan ... service providers are focused on introducing technology that directly improves bandwidth and latency for ...

Broadband providers hope to differentiate with value-added services: Report

Genie Life Sciences, a provider of cloud-connected laboratory orchestration solutions, announced today a new integration with the Opentrons OT-2 and F

Genie Life Sciences Announces a New Software Integration with the Opentrons OT-2 and Flex Lab Robots

VSSI Staffing Services, LLC., which provides staffing services, is closing its York location, according to a Pennsylvania Department of Labor & Industry WARN notice. According to the WARN notice, 180 employees are being affected as part of the closure.

VSSI Staffing Services closing York location, nearly 200 employees affected

Apptension

apptension

Building software can be complex. You might not have to think much about it when building your side project, but production software differs. It can require multiple components, all of which if not handled correctly can lead to chaos. But it doesn't need to be this complex. In today's article we will be delving into the world of architectural patterns, and discuss some divides your software into 3 simple components, each focusing on related tasks. Architectural patterns Whenever we are talking about architectural patterns in software design, the first ones to top the list include architectures like client-server, layered, monolithic, microkernel, even-driven, etc. These patterns are concerned with overall system architecture, including multiple applications, services, servers, etc. However, MVP, MVC, and MVVM focus on organizing code within a single application by separating data, user interface, and logic. These are a subset of architecture patterns that focus on the overall system. MVC, MVP, and MVVM For the sake of keeping the blog readable and not exceeding the word length, we will focus on just the architectural patterns that organize the code within a single application, namely: Model-View-Controller
Model-View-Presenter
Model-View-ViewModel Clearly, all three models have two components fixed, i.e. the Model and the View. So let's first discuss them in detail before coming to each of the architecture. Model The model consists of all the code that is related to data present in the software. It's the layer for communication of the database and network layers with the rest of the application. Its main responsibilities include: Handle data and business logic.


Encapsulate the application's data and the rules governing access to that data.


Handling data structures.


Performing CRUD (Create, Read, Update, and Delete) operations on data. View View is pretty much the front end of your application or everything that the user will be able to see and interact with. It's also known as the User Interface (UI) of your application. Its responsibilities include: Handle non-business logic and purely presentational logic.


Present the data provided by other layers to the user.


Receive user input and forward it to other layers.


May or may communicate directly with the Model layer. Model-View-Controller (MVC) Architecture Now that we have an understanding of what Model and View layers do, let's take a look at individual architectural patterns. Starting with MVC, it uses a Controller layer that communicates with both the Model and View layers. It's main responsibilities of the controller include: Manipulating data through the Model layer.
Receive instructions, aka the UI, from the View layer.
Update the View with changes defined due to control logic. Here, although the View layer cannot directly interact with the Model layer, it can however receive updates based on changes in the data. Hence all three layers are connected to each other in some form, with the controller being the main component. Model-View-Presenter (MVP) Architecture Here, the Presenter layer assumes the functionality of the "middle-man" between the Model and View layers and handles all the communication between them. There is no communication at all between the Model and View layers directly. Its responsibilities include: Update the UI or the View layer based on user actions.


Update the data or Model layer based on code logic.


Handle much of the business logic that would be otherwise handled in the controller in MVC architecture. Model-View-ViewModel (MVVM) Architecture This architecture at first glance is almost identical to MVP architecture. But there are some key differences between them: Multiple views can be mapped to a single ViewModel layer.


It uses data binding between the ViewModel layer and the View layer, making it more event-driven.


There is no concept of User Interface in this architecture. The View layer represents the actions of the user, not the interface. Side by Side comparison Aspect

MVC

MVP

MVVM



Full Name

Model-View-Controller

Model-View-Presenter

Model-View-ViewModel



Separation of Concerns

Basic

Better

Best



Data Flow

Two-way

One-way

One-way with data binding



View-Logic Relationship

Many-to-one

One-to-one

Many-to-one



Testability

Hard

Good

Best



Maintenance

Hard

Easy

Easy



Learning Curve

Easy

Easy

Harder



Performance

Can be slower due to tight coupling

Better performance with looser coupling

Smooth performance, especially for complex UIs



UI Updates

Controller updates View

Presenter updates View

ViewModel updates View through data binding



Dependency on UI Framework

High

Low

Low or no dependency



Scalability

Suitable for small-scale projects

Good for simple and complex projects

Ideal for large, data-heavy apps But which is the most popular you might ask? All of them are equally popular architectures being used according to the company's respective requirements for a product. Some companies adopting these different architectures are: MVC: StackOverflow, GoDaddy, Visual Studio website Dell
MVP: Google (for some Android apps)
MVVM: Apple (for some iOS apps using SwiftUI), Angular framework, Vue.js framework Also, many companies use a mix of these architectures depending on the specific needs of each project or product. The choice of architecture often depends on factors such as the complexity of the application, the development team's expertise, and the specific requirements of the project. Conclusion This article covered the basics of architectural patterns, from how overall architecture is designed to how a single application can be further divided into three components for better management and scalability. MVC, with its straightforward approach, remains popular for web applications.
MVP builds upon MVC's foundation, offering improved testability and a cleaner separation of concerns.
MVVM, the most recent of the three, has gained significant traction in modern application development. There is no clear winner between them and each pattern offers unique advantages and is suited to different projects and development scenarios. As the software development landscape continues to evolve, we may see further refinements of these patterns or the emergence of new architectures altogether. Want to learn more about the architectural patterns discussed? Here are some references I found helpful:

https://www.geeksforgeeks.org/android-architecture-patterns/
https://www.masaischool.com/blog/comparing-software-architecture-patterns/
https://www.apptension.com/blog-posts/mvc-vs-mvvm-vs-mvp Building software can be complex. You might not have to think much about it when building your side project, but production software differs. It can require multiple components, all of which if not handled correctly can lead to chaos. But it doesn't need to be this complex. In today's article we will be delving into the world of architectural patterns, and discuss some divides your software into 3 simple components, each focusing on related tasks. Architectural patterns Whenever we are talking about architectural patterns in software design, the first ones to top the list include architectures like client-server, layered, monolithic, microkernel, even-driven, etc. These patterns are concerned with overall system architecture, including multiple applications, services, servers, etc. However, MVP, MVC, and MVVM focus on organizing code within a single application by separating data, user interface, and logic. These are a subset of architecture patterns that focus on the overall system. MVC, MVP, and MVVM For the sake of keeping the blog readable and not exceeding the word length, we will focus on just the architectural patterns that organize the code within a single application, namely: Model-View-Controller Model-View-Presenter Model-View-ViewModel Model-View-Controller Model-View-Presenter Model-View-ViewModel Clearly, all three models have two components fixed, i.e. the Model and the View. So let's first discuss them in detail before coming to each of the architecture. Model The model consists of all the code that is related to data present in the software. It's the layer for communication of the database and network layers with the rest of the application. Its main responsibilities include: data Handle data and business logic. Encapsulate the application's data and the rules governing access to that data. Handling data structures. Performing CRUD (Create, Read, Update, and Delete) operations on data. Handle data and business logic. Handle data and business logic. Encapsulate the application's data and the rules governing access to that data. Encapsulate the application's data and the rules governing access to that data. Handling data structures. Handling data structures. Performing CRUD (Create, Read, Update, and Delete) operations on data. Performing CRUD (Create, Read, Update, and Delete) operations on data. View View is pretty much the front end of your application or everything that the user will be able to see and interact with. It's also known as the User Interface (UI) of your application. Its responsibilities include: Handle non-business logic and purely presentational logic. Present the data provided by other layers to the user. Receive user input and forward it to other layers. May or may communicate directly with the Model layer. Handle non-business logic and purely presentational logic. Handle non-business logic and purely presentational logic. Present the data provided by other layers to the user. Present the data provided by other layers to the user. Receive user input and forward it to other layers. Receive user input and forward it to other layers. May or may communicate directly with the Model layer. May or may communicate directly with the Model layer. Model-View-Controller (MVC) Architecture Now that we have an understanding of what Model and View layers do, let's take a look at individual architectural patterns. Starting with MVC, it uses a Controller layer that communicates with both the Model and View layers. Controller It's main responsibilities of the controller include: Manipulating data through the Model layer. Receive instructions, aka the UI, from the View layer. Update the View with changes defined due to control logic. Manipulating data through the Model layer. Receive instructions, aka the UI, from the View layer. Update the View with changes defined due to control logic. Here, although the View layer cannot directly interact with the Model layer, it can however receive updates based on changes in the data. Hence all three layers are connected to each other in some form, with the controller being the main component. Model-View-Presenter (MVP) Architecture Here, the Presenter layer assumes the functionality of the "middle-man" between the Model and View layers and handles all the communication between them. There is no communication at all between the Model and View layers directly. Its responsibilities include: Update the UI or the View layer based on user actions. Update the data or Model layer based on code logic. Handle much of the business logic that would be otherwise handled in the controller in MVC architecture. Update the UI or the View layer based on user actions. Update the UI or the View layer based on user actions. Update the data or Model layer based on code logic. Update the data or Model layer based on code logic. Handle much of the business logic that would be otherwise handled in the controller in MVC architecture. Handle much of the business logic that would be otherwise handled in the controller in MVC architecture. Model-View-ViewModel (MVVM) Architecture This architecture at first glance is almost identical to MVP architecture. But there are some key differences between them: Multiple views can be mapped to a single ViewModel layer. It uses data binding between the ViewModel layer and the View layer, making it more event-driven. There is no concept of User Interface in this architecture. The View layer represents the actions of the user, not the interface. Multiple views can be mapped to a single ViewModel layer. Multiple views can be mapped to a single ViewModel layer. It uses data binding between the ViewModel layer and the View layer, making it more event-driven. It uses data binding between the ViewModel layer and the View layer, making it more event-driven. There is no concept of User Interface in this architecture. The View layer represents the actions of the user, not the interface. There is no concept of User Interface in this architecture. The View layer represents the actions of the user, not the interface. Side by Side comparison Aspect

MVC

MVP

MVVM



Full Name

Model-View-Controller

Model-View-Presenter

Model-View-ViewModel



Separation of Concerns

Basic

Better

Best



Data Flow

Two-way

One-way

One-way with data binding



View-Logic Relationship

Many-to-one

One-to-one

Many-to-one



Testability

Hard

Good

Best



Maintenance

Hard

Easy

Easy



Learning Curve

Easy

Easy

Harder



Performance

Can be slower due to tight coupling

Better performance with looser coupling

Smooth performance, especially for complex UIs



UI Updates

Controller updates View

Presenter updates View

ViewModel updates View through data binding



Dependency on UI Framework

High

Low

Low or no dependency



Scalability

Suitable for small-scale projects

Good for simple and complex projects

Ideal for large, data-heavy apps Aspect

MVC

MVP

MVVM Full Name

Model-View-Controller

Model-View-Presenter

Model-View-ViewModel Separation of Concerns

Basic

Better

Best Data Flow

Two-way

One-way

One-way with data binding View-Logic Relationship

Many-to-one

One-to-one

Many-to-one Testability

Hard

Good

Best Maintenance

Hard

Easy

Easy Learning Curve

Easy

Easy

Harder Performance

Can be slower due to tight coupling

Better performance with looser coupling

Smooth performance, especially for complex UIs UI Updates

Controller updates View

Presenter updates View

ViewModel updates View through data binding Dependency on UI Framework

High

Low

Low or no dependency Scalability

Suitable for small-scale projects

Good for simple and complex projects

Ideal for large, data-heavy apps Aspect MVC MVP MVVM Aspect Aspect MVC MVC MVP MVP MVVM MVVM Full Name Model-View-Controller Model-View-Presenter Model-View-ViewModel Full Name Full Name Model-View-Controller Model-View-Controller Model-View-Presenter Model-View-Presenter Model-View-ViewModel Model-View-ViewModel Separation of Concerns Basic Better Best Separation of Concerns Separation of Concerns Basic Basic Better Better Best Best Data Flow Two-way One-way One-way with data binding Data Flow Data Flow Two-way Two-way One-way One-way One-way with data binding One-way with data binding View-Logic Relationship Many-to-one One-to-one Many-to-one View-Logic Relationship View-Logic Relationship Many-to-one Many-to-one One-to-one One-to-one Many-to-one Many-to-one Testability Hard Good Best Testability Testability Hard Hard Good Good Best Best Maintenance Hard Easy Easy Maintenance Maintenance Hard Hard Easy Easy Easy Easy Learning Curve Easy Easy Harder Learning Curve Learning Curve Easy Easy Easy Easy Harder Harder Performance Can be slower due to tight coupling Better performance with looser coupling Smooth performance, especially for complex UIs Performance Performance Can be slower due to tight coupling Can be slower due to tight coupling Better performance with looser coupling Better performance with looser coupling Smooth performance, especially for complex UIs Smooth performance, especially for complex UIs UI Updates Controller updates View Presenter updates View ViewModel updates View through data binding UI Updates UI Updates Controller updates View Controller updates View Presenter updates View Presenter updates View ViewModel updates View through data binding ViewModel updates View through data binding Dependency on UI Framework High Low Low or no dependency Dependency on UI Framework Dependency on UI Framework High High Low Low Low or no dependency Low or no dependency Scalability Suitable for small-scale projects Good for simple and complex projects Ideal for large, data-heavy apps Scalability Scalability Suitable for small-scale projects Suitable for small-scale projects Good for simple and complex projects Good for simple and complex projects Ideal for large, data-heavy apps Ideal for large, data-heavy apps But which is the most popular you might ask? All of them are equally popular architectures being used according to the company's respective requirements for a product. Some companies adopting these different architectures are: MVC: StackOverflow, GoDaddy, Visual Studio website Dell MVP: Google (for some Android apps) MVVM: Apple (for some iOS apps using SwiftUI), Angular framework, Vue.js framework MVC: StackOverflow, GoDaddy, Visual Studio website Dell MVP: Google (for some Android apps) MVVM: Apple (for some iOS apps using SwiftUI), Angular framework, Vue.js framework Also, many companies use a mix of these architectures depending on the specific needs of each project or product. The choice of architecture often depends on factors such as the complexity of the application, the development team's expertise, and the specific requirements of the project. Conclusion This article covered the basics of architectural patterns, from how overall architecture is designed to how a single application can be further divided into three components for better management and scalability. MVC, with its straightforward approach, remains popular for web applications. MVP builds upon MVC's foundation, offering improved testability and a cleaner separation of concerns. MVVM, the most recent of the three, has gained significant traction in modern application development. MVC, with its straightforward approach, remains popular for web applications. MVP builds upon MVC's foundation, offering improved testability and a cleaner separation of concerns. MVVM, the most recent of the three, has gained significant traction in modern application development. There is no clear winner between them and each pattern offers unique advantages and is suited to different projects and development scenarios. As the software development landscape continues to evolve, we may see further refinements of these patterns or the emergence of new architectures altogether. Want to learn more about the architectural patterns discussed? Here are some references I found helpful: https://www.geeksforgeeks.org/android-architecture-patterns/
https://www.masaischool.com/blog/comparing-software-architecture-patterns/
https://www.apptension.com/blog-posts/mvc-vs-mvvm-vs-mvp Want to learn more about the architectural patterns discussed? Here are some references I found helpful: https://www.geeksforgeeks.org/android-architecture-patterns/ https://www.masaischool.com/blog/comparing-software-architecture-patterns/ https://www.apptension.com/blog-posts/mvc-vs-mvvm-vs-mvp https://www.geeksforgeeks.org/android-architecture-patterns/ https://www.geeksforgeeks.org/android-architecture-patterns/ https://www.masaischool.com/blog/comparing-software-architecture-patterns/ https://www.masaischool.com/blog/comparing-software-architecture-patterns/ https://www.apptension.com/blog-posts/mvc-vs-mvvm-vs-mvp https://www.apptension.com/blog-posts/mvc-vs-mvvm-vs-mvp

Architecture Patterns for Beginners: MVC, MVP, and MVVM

I have often been asked what resources would I recommend for beginners looking to step their foot into the web development career. I often refer to GitHub as a great place to start. I decided to compile some of the best repositories I know. I wish I knew them when I started myself, so treat them as a valuable shortcut to speed up your learning path. This article is obviously oriented on beginners, though I'm sure some of the more experienced developers might learn a thing or two from these, too. To help you to navigate I have arranged them via categories, starting from basics to courses, handbooks, best practices, projects, interviews, and resources. Fundamentals ⚡ 1. how-web-works ⭐ GitHub stars 4k+ https://github.com/vasanthk/how-web-works What happens behind the scenes when we type in a browser? www.google.com 2. developer-roadmap ⭐ GitHub stars 187k+ https://github.com/kamranahmedse/developer-roadmap This is probably the best and most complete roadmap, that will help you to grasp the bigger picture of the development landscape, its main technologies, and the recommended sequence of learning things. Courses 👨‍🏫 3. web-dev-for-beginners ⭐ GitHub stars 41k+ https://github.com/microsoft/Web-Dev-For-Beginners Quality 12-week, 24-lesson course about JavaScript, CSS, and HTML basics. Each lesson includes pre-and post-lesson quizzes, written instructions to complete the lesson, a solution, an assignment, and more. 4. javascript-30 ⭐ GitHub stars 18k+ https://github.com/wesbos/JavaScript30 Starter Files + Completed solutions for the JavaScript 30 Day Challenge by Wes Bos. Handbooks 📚 5. developer-handbook ⭐ GitHub stars 1k+ https://github.com/apptension/developer-handbook An opinionated guide on how to become a professional Web/Mobile App Developer. 6. spellbook-of-modern-webdev ⭐ GitHub stars 14k+ https://github.com/dexteryy/spellbook-of-modern-webdev A Big Picture, Thesaurus, and Taxonomy of Modern JavaScript Web Development. Best Practices 💯 7. web-fundamentals ⭐ GitHub stars 12k+ https://github.com/google/WebFundamentals Some of the best practices for modern web development, provided by Google developers. 8. airbnb ⭐ GitHub stars 120k+ https://github.com/airbnb/javascript One of the best Style Guides out there. 9. clean-code-javascript ⭐ GitHub stars 64k+ https://github.com/ryanmcdermott/clean-code-javascript Software engineering principles, from Robert C. Martin's book "Clean Code", adapted for JavaScript. A guide to producing readable, reusable, and refactorable software in JavaScript. 10. system-design-primer ⭐ GitHub stars 164k+ https://github.com/donnemartin/system-design-primer Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards. Projects 📂 11. simpl ⭐ GitHub stars 4k+ https://github.com/samdutton/simpl Simplest possible examples of HTML, CSS, and Javascript. 12. realworld ⭐ GitHub stars 64k+ https://github.com/gothinkster/realworld Realworld allows you to choose any frontend (React, Vue, & more) and any backend (Node, Django, & more) and see how they power real-world, beautifully designed full-stack apps. 13. build-your-own-x ⭐ GitHub stars 133k+ https://github.com/danistefanovic/build-your-own-x Build your own (insert technology here). Interviews 💼 14. coding-interview-university ⭐ GitHub stars 211k+ https://github.com/jwasham/coding-interview-university A complete computer science study plan to become a software engineer. 15. front-end-interview-handbook ⭐ GitHub stars 32k+ https://github.com/yangshun/front-end-interview-handbook Front End interview preparation materials for busy engineers. 16. tech-interview-handbook ⭐ GitHub stars 66k+ https://github.com/yangshun/tech-interview-handbook Curated interview preparation materials for busy engineers. Resources 💾 17. design-resources-for-developers ⭐ GitHub stars 36k+ https://github.com/bradtraversy/design-resources-for-developers A curated list of design and UI resources from stock photos, web templates, CSS frameworks, UI libraries, tools, and much more. 18. free-programming-books ⭐ GitHub stars 223k+ https://github.com/EbookFoundation/free-programming-books Freely available programming books. 19. front-end-collection ⭐ GitHub stars 1k+ https://github.com/cheatsheet1999/FrontEndCollection Notes for Front-end Software Engineers. Covers common data structure and algorithms, basic web concepts, HTML & CSS & Javascript. Writing has always been my passion and it gives me pleasure to help and inspire people. If you have any questions, feel free to reach out! If these resources helped, connect me on , , and ! Twitter LinkedIn GitHub Visit my for more articles like this. Also published . Blog here

19 GitHub Repositories to Make you a 10x Developer

19 repositorios de GitHub para convertirte en un desarrollador 10x

The Best 75 Evernote Alternatives:  Complete Review

Top Custom Software Development Companies

Containers are hard. Containers are all over our tech devices. Files in a file system. Tabs in a browser. Windows in a desktop shell. Applications on a smart phone. Objects inside a compound document. (I’ll skip extending this discussion to the common use of the word “containers” in the context of cloud services but no doubt many of the dynamics discussed here play out in that context as well.) What’s so hard about containers? The biggest problems arise because we have two opposing dynamics. We would like to keep the container-object interface as simple as possible. The container knows little about the objects it contains and the objects know little about the container. Knowledge implies complexity, tighter binding, more constraints on future development and greater development effort on both sides of the interface. The more knowledge objects have about the container, the harder it is to evolve the container forward — that knowledge represents constraints. More knowledge also means it is generally harder to integrate new object types into a container — lots of “things to know” often map to required features or other constraints on the ways objects need to be implemented. The opposing dynamic is that this tighter binding often represents better integration and a better overall user experience — at least in the short term — and more functionality. So the container-object interface starts simple and gets more and more complex over time as new features are added. Over time this tighter binding makes it harder to create new object types and harder to evolve the container. I have mostly struggled with these issues in the context of desktop systems and document applications but the motivation for this post came when I bought a new Audi A3 with Apple CarPlay. The A3 comes with a small pop-up screen on the dash that displays Audi’s default shell interface and gives you access to car settings, navigation, maps, radio, telephone, etc. There is one big clickable round knob for navigating around and selecting something and then a range of other dedicated hardware buttons to drill directly down into specific functions — radio, map, telephone, top-level menu and a “back” button. When you plug your iPhone in, Apple CarPlay becomes one of the top-level choices in the Audi menu. When you select CarPlay, it takes over the entire screen and presents an interface that looks like the home screen of your iPhone, but only shows those applications (mostly Apple’s own) that explicitly support a CarPlay interface. These include maps and a phone UI that overlap the functionality of Audi’s components. You immediately run into a pretty classic container problem — “who’s on top”? Both top-level interfaces want to be on top. They each provide a way to drill into the other container but no other way to expose capabilities from one to the other. If I try to use the hardware buttons, e.g. to drill directly to the telephone interface, I get told that the telephone interface is unavailable (rather than plumbing me through to CarPlay’s telephone interface). The “map” button gets me to Audi’s (inferior) map component rather than the map component in Apple CarPlay. The “back” button works within either container but does not cross containers. So if I select the radio with the hardware button while in CarPlay, I cannot get back to the CarPlay interface without navigating back to Audi’s top-level menu and selecting CarPlay from there. (This scenario arises trivially when I want to interact with the radio while using the Apple navigation feature.) Each of these issues are relatively minor and you can certainly imagine extending the interface between Audi’s container and CarPlay to support these features. Each of these new features (like drilling through with hardware buttons) involves additional work on both sides of the interface and a tighter binding between the systems. In some cases this binding is further complicated because it introduces ambiguity in the interface. For example it seems clear that drilling through to Apple’s phone interface is better than saying “phone not available” but a user might want the choice of which mapping interface to support when pressing the map button. As Audi adds better support for CarPlay it needs to ensure that its own new feature development doesn’t degrade that integration (this type of problem is very common especially if the internal group thinks that it is in some sense “competing” with the other container or treats integration as a post-development verification phase rather than a real ongoing constraint on development and feature selection). Let’s look at another example — window systems and the evolving relationship between applications and the containing window manager. This offers a good case study since it has played out over 30 years — many of the issues associated with these opposing dynamics only arise over time because they are often about how current decisions create future constraints. I’ll look at Windows in particular but similar issues played out on other OS’s. (This story is a significant simplification of the full history.) Windows defined a top-level application window and applications could implement a “multiple document interface” (MDI) if they wanted a single application process to support multiple documents — e.g. Excel allowing you to have multiple worksheets open at once. Library routines supported standard ways of interacting with these child windows but applications could relatively easily support their own separate features — e.g. Excel supporting multiple windows on a single document and keeping the contents of the windows aligned or Word supporting side-by-side windows when doing document compare. Later versions of Windows then moved to extend and promote support for “single document interface” (SDI) where a single application could maintain multiple separate top-level rather than child windows. SDI support came with features in the task bar and other window management functionality to better support applications with multiple windows. The disadvantage was both the work required in each application to adapt to this change as well as work to design how app-specific functionality (like Excel’s side-by-side linked scrolling) could be retrofitted in this new design. The work was complicated enough that it was a decade before Excel fully integrated with this new user experience. Excel implemented “fake SDI” (with specific OS support for this mode) that “sort-of” worked for some usage modes but was totally busted for others. The work to adapt to the new Windows 8 and WinRT interfaces again broke the user interface for applications with multiple documents that wanted to code to these new APIs. Windows was initially focused on applications that did not need this type of support but knew that they would need to add it in the future. They did not want Office going off and designing application-specific solutions that would later need to be retrofitted or constrain what the OS could do. Office agreed this was an OS (container) responsibility but disagreed with the prioritization. It was a long-standing source of friction but ultimately was of limited impact because of the overall poor reception of Windows 8 and the limited availability of devices running this interface. Browsers also innovated in this space with the addition of explicit tabs for switching between open pages. Initially tabs were a completely internal application feature but over time the OS shell added support for directly activating an open tab. The latest release of Windows is adding direct OS support for tabs to both expand the supported scenarios (e.g. different applications per tab) as well as ensure the feature is provided in a consistent way within applications. This required yet another significant development effort within the Office applications in order to integrate smoothly. (Or not — I haven’t actually used the new feature yet so can’t speak to how well the feature and application integration works. See for more details.) this post The general pattern here is that for simple and “vanilla” scenarios, adapting to continued container evolution is relatively straightforward. As scenarios become more complex and objects (applications in this case) integrate more tightly with the current design, evolving that support over time becomes more difficult. This tighter integration is initially welcomed by the container team as an example of a committed partner. Later generations of the same container team see this tight integration as sclerotic legacy — and generally the “fault” of the object team. (This is of the flavor “you screwed up, you trusted us”.) OLE is another good test case. Object linking and embedding (OLE) was initially viewed as a major breakthrough in how to build compound documents. OLE 1.0 was fairly simple, with limited goals and limited integration. Essentially objects had a way of persisting their state into the document and a way of displaying their content on the document surface. OLE 2.0 was a frenzy of complexity with a hairy menu-merging mechanism to combine the UI of the host container and object as well as many additional APIs to more tightly integrate the container and object content. In-place activation and drag-and-drop support were a few of the features. That version of the container-object interface essentially crashed on the shoals of complexity from the start, with few new containers or objects that were willing to implement the full API. Despite the limited number of new object types in the ecosystem, the feature added ongoing overhead and container constraints for new feature development for all subsequent versions of the Office applications. OLE 2.0 is a useful cautionary tale for another reason. The high-level scenario — “insert an editable Excel sheet in a Word document” was simple to state but required an explosion of underlying complexity. Within Microsoft, most pushback on feature ideas would come because of the amount of development time required, not because of the additional complexity introduced. These are often linked but not always. In fact, ActiveX, supported in Internet Explorer as an extension mechanism for the web, was a significant simplification and trimming of the OLE APIs. It got non-trivial usage for internal line-of-business applications but the lack of a cross-platform solution or a secure distribution mechanism (essentially an app store) doomed it in the longer term. I’m being a little unfair to OLE. There is successful example of an object-embedding technology for editable documents. Just achieving sufficient baseline functionality to give the appearance of a consistent holistic document results in an astounding degree of complexity in the container-object interface. This dooms the effort early on. The battle between extensible compound documents and monolithic documents has been won by the monolith exactly because of these complexity challenges. no HTML has seen success with a very simple embedding approach using IFRAME’s, but this omits all the complexity of editing which would add an immense degree of additional feature requirements. I have no “solution” for the tensions described here — they are really inherent to the structure of the design challenge. Knowing the tension exists can be helpful in balancing where you want to create tighter integration as you add new features and where you want to avoid that binding and the future constraints it implies — perhaps by saying “no” to some feature request or at the least recognizing that the bar should be high to OK these types of features. For any specific feature, there are often ways to minimize the assumptions made across this interface while still achieving the feature goals. That is obviously the goal for any API design but plays an even bigger role in problems of this form.

Containers are Hard

Being halfway through 2017, we think that it’s a good moment to analyze the predominant mobile app development trends. We’ve noticed that our clients are getting more and more interested in developing innovative mobile apps. We also want to keep an eye on the latest technology trends shaping mobile landscape, trending programming languages, or crucial security updates. Now, we want to share these trends with you in this article. Tech related mobile app development trends you need to pay attention to in 2017 We’re covering the tech-side of mobile app development trends, as it shapes the way the apps are being built, be it a messaging, travel or shopping app. Without further ado, let’s get to the 9 trends we found crucial for mobile app development in 2017: 1. More AR apps With an undeniable success of games like Pokemon Go or AR filters in messaging apps like Snapchat and Instagram, we’ve already seen how popular augmented reality applications may be. And the trend is about to grow, as more businesses will try to implement AR to showcase their products. One of the examples of how to bring AR and retail together, is the to create an application that will help to showcase IKEA’s furniture in buyers house. It will use Apple’s ARKit, and the new products will first be available through the app. joint effort of Apple and IKEA If the app proves to be successful, other manufacturers from various industries will follow. 2. AI will change the tech The advancements in AI change the way we interact with mobile apps. Virtual assistants like Siri, Cortana and Google Assistant can now help us with gathering information, organize our schedules or optimize our productivity. The developments in Natural Language Processing and machine learning make virtual assistants more contextually aware, making their responses better and more accurate. Machine learning is, according to Venture Scanning, the most funded category amongst AI-based ventures, reaching $2B. At the same time, big companies like Facebook, Microsoft, Google and Amazon invest in solutions based on machine learning to create better conversational interfaces. Last year we’ve seen mobile apps like Prisma, that used neural networks and AI to create what other thought a simple filter could do. The effect was stunning and we can expect other app developers to experiment with similar solutions. Do you want to build a mobile application for your business? and let us do the code! Drop us a line 3. Security remains developers’ top concern In 2017 mobile app security is one of the most important trends. The general growth of the industry, billions of users, 3rd party SDKs and the vast number of user data being stored by the companies made a security a top concern for mobile app developers. We’ve already seen a growing trend of encrypted messaging apps like Telegram, mobile browsers protecting users’ privacy and an industry shift towards protecting user data, including Apple’s App Transport Security (ATS) and Google’s efforts to improve app permissions. At the same time, both companies included automatic security updates for their OSes. We’ll definitely see more improvements in mobile security in 2017, especially in mobile payments, data encryption and privacy protection. 4. Location-based applications Location-based apps are going to expand, as location-based services (LBS) change how users interact with businesses. Innovations in location intelligence and the ability to track places user visited, help marketers and publishers better target their customers, offering relevant ads. We will see the especially in tourism and travel, navigation, security features, retail offers, location-specific payment portals, and indoor mapping. growth of LBS-based apps What do we use location-based apps for. Source: The App Solution And with easily available APIs and Google map technology, it’s now easier than ever for mobile app developers to create location-based solutions for the users. 5. Android: Kotlin vs Java Kotlin has become an alternative to Java for Android developers, similar to Swift and Objective-C on iOS. Its growing popularity and successful use in commercial projects make 2017 the year when Kotlin will finally take off on a bigger scale. The reason for that is the ease of use. Kotlin for Java developers is pretty easy, as well as for C# developers, as both languages share some similarities. Developers can also use Kotlin and Java in one project, as they work together smoothly. They can also use it with Android Studio, a from IntelliJ. Learning tool It also helps to avoid some Java pitfalls, like null references, which increases products’ quality. That’s why Kotlin is being named and we will see more Android apps using it. “Java on steroids” 6. iOS: Swift will continue to grow Swift’s growing popularity will not stop in 2017, as it is considered a powerful and easy-to-learn mobile programming language. With its concise syntax and clear documentation, Swift in considered smoother in comparison to Objective-C. And just like Kotlin and Java, Swift and Objective-C can be used in the same projects, with full access to Objective-C API. Swift will maybe not take over Objective-C this year, but we will find more and more iOS application based on it. 7. Accelerated Mobile Pages Loading speed is still a crucial factor for mobile users. In order to improve it, Google has introduced Accelerated Mobile Pages. It is an open source project aiming to improve mobile browsing experience. You can easily recognize AMP-based website searching Google on mobile, as they are marked as such. Web developers, businesses and publishers will need to consider this solution, as it not only improves the user experience on mobile, but is also an SEO factor (AMP websites rank higher in Google). At the same time, it is cheaper to develop and maintain the AMP than building a native or hybrid mobile application. AMP and PWA comparison. Source: Smashing Magazine 8. Progressive Web Apps Progressive Web Apps (PWA) have been dubbed the next generation of mobile web apps. They are free from constraints of mobile websites like slow speed and the need of constant Internet connection. PWAs bring a native-like feel with features including offline and full screen modes, a homescreen launcher, an access to the camera and push notifications. Plus, they are faster and consume less data than mobile websites. Progressive Web Apps don’t require downloading and installation, which is the answer to mobile fragmentation and multiple operating systems. Some companies, like the Financial Times, have already dropped native apps in favor of PWAs, and other ones like Twitter introduced a lighter, progressive alternative for their own native apps (e.g., Twitter Lite). With of popular applications like Flipboard, AliExpress or Telegram, we can expect a shift towards PWAs. the growing list of Progressive Web Apps 9. Android Instant Apps Considering the high number of mobile applications in the app stores, Google realized how daunting it is for the users to download and update new apps every now and then, for different purposes. That’s why the company introduced its Android Instant Apps, previewed during the Google I/O developer conference this year. With Android Instant Apps users can download only the most needed parts of the application, accessing the rest of the content instantly through the URL, saving space on the device. Android Instant Apps are being developed simultaneously with Google’s Progressive Web Apps. , there have been 50 instant apps developed already, and developers can easily transform their native apps into instant ones, without the need to build a separate application. According to Google Conclusion These trends definitely shape how mobile websites and applications look like today. Whether you want to create the next chat app, photo-sharing platform or carpooling service, many of these trends are applicable for you. Do you want to build a mobile application for your business? Drop us a line and let us do the code! Is there anything else you would like to share regarding mobile trends? Please, feel free to leave us a comment! Originally published at blog.apptension.com on July 27, 2017.

9 Mobile App Development Trends To Watch In 2017

Image source: Unsplash The idea of is nothing new. What’s changed is that for the past two years companies have been more focused on creating them than ever before. chatbots It didn’t, however, happen overnight. People have been interested in creating a robot able to communicate with humans (just to mention , and ). since the early 1960s ELIZA ALICE SmarterChild Since then, we’ve made a huge step forward. We now have AI assistants like Siri and Cortana, home assistants like Amazon Echo or Home. There are more than alone. Google 100,000 bots on the Messenger Platform This Google Trends graph shows how the popularity of the term Chatbots has taken off since the beginning of 2016 According to Business Insider, . 80% of businesses want to use chatbots by 2020 In this article, we want to answer the following question: Why did chatbots become popular? Industry experts, including HubSpot founder and CTO Dharmesh Shah, list : two main reasons for that Growing popularity of messaging platforms Advancement in AI and machine learning First, the way we communicate (and especially chat) has changed drastically since we’ve moved from phone calls to texts, and then to messaging apps. Now the companies have realized realized that chatbots are able to help various industries to reach, engage and serve their customers like never before, 24/7. Second, the current state of the AI, Natural Language Processing (NLP) and voice recognition enables bots to better understand users’ queries and to answer them accordingly. In fact, chatbots are becoming new interfaces in messaging apps, replacing many other mobile applications. “What 1997 was to Internet and browsers, 2017 is to bots.” — Dharmesh Shah, HubSpot founder and CTO Let’s take a closer look at the factors that made chatbots so popular. Messaging platforms trumped social networks Chatbots have become a vital part of messaging platforms’ ecosystem. In 2015, top 4 messaging platforms exceeded the biggest 4 social networking apps in the number of monthly active users, . according to Business Insider Source: Business Insider In April 2016, Facebook introduced their , opening up for bots developers. Facebook’s bet on chatbots was aimed to simulate “one-on-one conversations between users and companies [to] expand its reach in customer service and enterprise transactions”. Messenger developer platform As the Messenger alone has already , and Facebook is reaching almost , there are vast possibilities of using the data collected by the company to create more personalized chatbots, able to e.g. book a flight or make payments. 1.2 billion monthly active users 2 billion people “Chat apps will come to be thought of as the new browsers; bots will be the new websites. This is the beginning of a new Internet.” — , founder of Kik Ted Livingston Another thing is that the way we expect brands to communicate with customers has also changed. Today, we want companies to be available 24/7. This is now possible with bots, which can answer the majority of questions and to respond immediately. And, if needed, a human consultant can jump into the conversation at any time. Source: The 2016 Mobile Messaging Report Given that more than consider messaging their primary method of communication, chatbots may also increase the tech adoption amongst generations, helping brands to reach broader potential audience. 65% of Millenials, Gen Xers and Boomers Bots are the new apps Let’s face it — users are tired of apps. Since the introduction of iPhone and the App Store, programmers worldwide have developed more than 6,5 million apps . for all platforms Source: Statista.com Users and brands are fed up with apps for various reasons. For users, it’s become exhausting to install new apps and learn how to use them just to abandon them after few days. Actually, after just one use, according to Localytics survey based on 37,000 apps. 23% of users abandon the app Brands, on the other hand, find it harder than ever to acquire new users, as the competition became fierce. And, considering the high cost of developing the apps and the abandonment rate, many companies realized that it may not be cost-efficient to build their own, branded apps. Here’s where the chatbots come into play. They are cheaper, easier and faster to , making them a great tool for companies to test and implement their campaigns. As for the users, they are also easier to install and use, since everything takes place in a messaging app. develop and experiment with Bot platforms and developer tools The biggest tech brands like Facebook, Microsoft and Google made their bet on bots, introducing their own bot platforms. After acquiring , Google reached around 60,000 bot developers. There are now over 45,000 developers on Microsoft’s , and around 34,000 developers use the Facebook’s . API.ai Bot Framework Messenger Platform For Facebook alone, it resulted in more than 30,000 bots being created in the first six months after introducing its bot platform, . Wall Street Journal says There are also other platforms for bot developers available, such as the , and bot stores like or . Telegram Bot Platform Botlist Kik’s Bot Shop Furthermore, developers can use tools like or , based on deep learning algorithms and Natural Language Processing to build conversational interfaces of their bots. IBM’s Watson Conversation Amazon Lex Microsoft CEO Satya Nadella says that , calling them “conversations as a platform”. He compared conversational bots to breakthroughs like graphical user interfaces, browsers and touchscreens. chatbots will become the new interfaces “Chatbots will fundamentally revolutionize how computing is experienced by everybody.” — Satya Nadella, Microsoft CEO The has resulted in 59% of US Millenials and 60% of gen Xers using them on messaging apps so far. And the numbers are still to grow. popularity of chatbots Source: BI Intelligence Conclusion Although the chatbot experience with chatbots, they are far better than they were just a couple years ago. is not yet perfect They are now able to assist us in some basic tasks that may be automated, saving our time and money. And given the popularity of messaging apps and the way that chatbots fit this platform, plus advancement in AI, machine learning and NLP, the trend of developing more and more chatbots is not going away. Thing to be discussed next is not whether the chatbots are here to stay, but what kind of bots we actually need. Now, we’d like to ask you one question: Which industries are, in your opinion, yet to be disrupted by the chatbots? Leave the answers in the comments, we’d love to read your thoughts about it! Originally published at blog.apptension.com on July 18, 2017.

What Drives The Growing Popularity Of Chatbots?

If you had to guess what is it that programmers hate the most, what would you say? A Quora thread asking this question triggered over 90 replies and nearly 450k views. Clearly, there are some strong sentiments on this issue. What struck me the most is that some of the problems these developer complained about are very much avoidable. In this article I want to show you project management best practices implemented at our company, that help us to maintain a proper workflow and keep our employees motivated. I thought that it would be interesting to ask the developers whom I work with at Apptension, if there are things that they don’t like, so that I could compare their views with the Quora answers. Avoid These Mistakes While Working With Programmers At Apptension we do our best to maintain a happy and productive workspace, which we’ve included in our employer branding strategy. So I asked my co-workers this one question: What do programmers hate? Here’s what they told me. 1. Lousy requirements Sometimes it’s the requirements gap, unspecified project or unclear communication between the client, project managers and developers that leads to flawed software. If a client or a manager isn’t specific enough about their product, they shouldn’t expect others to read their minds and do the work they haven’t addressed properly. It is a manager’s job to gather as complete project’s specifications as possible, so the developers don’t need to guess or ask about the specs. 2. Repeatable tasks Doing things over and over again can not only be boring, it can be exhausting. The problem here may be, for example, working on one project for a long time. It may also be a client changing their mind all over again on one feature. Either way, if a developer feels burnt out by the repeatable tasks they are doing, maybe it’s time for you to talk about it with them. If you can, relocate your employee to another project. Sometimes a simple change of the tasks one is working on can be refreshing and keep this employee motivated. At Apptension we use Officevibe for anonymous employee surveys, to measure their satisfaction. 3. Technical debt Technical debt is an effect of using a simple solution without thinking about future scalability of the project. In other words: it’s the result of choosing a quick & easy way to do something right now, which is not necessarily the best solution. The reason why developers hate technical debt is simple: Just like it is the case with the financial debt, there will be a moment to “pay it back”, which in development means tackling the same problem again. To fix it, developers often need to rewrite the code to finish “the uncompleted work”. It also causes missing deadlines, as it is hard to estimate how much work is required to pay of the debt. The solution: don’t fall into something because it seems to be easier when you plan it. Think about the best possible solution and execute it once and for all. 4. Not enough or too many tasks Employee underutilization can result in reduced motivation, while too many assignments lead to burnout. A good company can prevent both by implementing proper resource management. Tools like teamdeck can help maintaining the right resource flow between the projects, and monitoring team’s utilization. 5. Interruptions It takes up to 45 minutes for a programmer to get into the so called “zone”, which is a state of the deepest focus, assuring the biggest productivity. Getting out of it is much faster, on the other hand. Sometimes all it takes is a question asked in person or via messengers like Slack. Another form of interruption is context switching. It happens, for example, when a developer is working on several different projects during the day. It might actually cause losing time or project delays for the company, as employees need some time to switch from one project to another one. While managing the project, try to plan every detail of it and avoid interrupting developers during their work. For small interruptions it is common to implement “the headphones rule”, which means that if a developer is wearing them, do not approach them. Important issues regarding the project try to tackle during scrum meetings — that’s what they are for. It will make their work less stressful and more efficient. 6. Unnecessary meetings Not every meeting should actually take place. And certainly you don’t need to have developers involved in the majority of them. There are, however, meetings that require a presence of developers, like sprint plannings, project reviews or retrospectives. Here they can answer technical questions or to comment on the process. Scheduling a meeting, decide if the developers should really be a part of it. If not, they can spend their time more effectively working on a given project. 7. Bad QAs It is important to assure that the code is of high quality, and most developers understand the role of QAs. What programmers hate, are unqualified testers, who interrupt their work instead of improving the code with meaningful reports. Bad QAs are especially annoying and disruptive when they prioritize wrong issues, focus on sitters instead of major issues, or when they leave out key information in bug reports. Good testers, on the other hand, can preserve the quality of the software and help developers in their work, instead of interrupting it. While hiring Quality Assurance team members, do your best to make the best choice, because it will not only result in great quality of the software, but also make the partnership between them and developers less painful. 8. Unclear schedules For every task in software development there should be a clear due time. Milestones help to define when a certain feature should be completed, and when the developers are supposed to deploy the product. An unclear schedule or a lack of it makes it harder for the team to assume the priorities of a project, and to deliver it on time. Another reason for creating better schedules is a team-based nature of developers’ work, often requiring to sync several people to deliver a given feature. Running a project, analyze every stage of it, including scrum meetings, due dates for delivering the features, and shipping date. Then mark them in developers’ calendars. 9. Not including events in sprint planning Consistent project management helps developers to focus on the right tasks at the right time. Including events like Sprint Review, Retrospective, Planning, and Daily Standups in developer’s calendar assures the proper flow of the project. Without doing that, every call for a meeting will be an interruption for a programmer, and you already know that it is both annoying and disruptive for them. 10. Estimating tasks in hours Estimating tasks in hours is often considered as tea-leaf reading. As programming tasks can take different amount of time for various employees, it’s hard to set a clear timeline of finishing them. Yet, still many managers ask for time estimates and treat them as deadlines. Although it is important for a company to estimate how long a given project will take, it should be done based on the recent, alike projects, and always assume that it doesn’t mean that a new one will take this exact amount of hours. To improve your estimations, you can consider story points. It is a Scrum concept used to estimate work effort on a story. Story points include the amount of work and its complexity. If a company keeps track on story points, they can better estimate projects based on similar stories from the past. Conclusion Knowing these developers’ pain points, you can keep your employees motivated and focused on the right things. Avoiding them in your company may help in creating a happier workplace for your team. And as study shows, happy employee is up to 12% more productive than unhappy one. Is there anything you’d like to add to this list? Feel free to share it with us in the comments. Originally published at blog.apptension.com on April 20, 2017. If you had to guess what is it that programmers hate the most, what would you say? A Quora thread asking this question triggered over 90 replies and nearly 450k views. Clearly, there are some strong sentiments on this issue. What struck me the most is that some of the problems these developer complained about are very much avoidable. In this article I want to show you project management best practices implemented at our company, that help us to maintain a proper workflow and keep our employees motivated. management I thought that it would be interesting to ask the developers whom I work with at Apptension , if there are things that they don’t like, so that I could compare their views with the Quora answers. Apptension Avoid These Mistakes While Working With Programmers At Apptension we do our best to maintain a happy and productive workspace, which we’ve included in our employer branding strategy . our employer branding strategy So I asked my co-workers this one question: What do programmers hate? Here’s what they told me. 1. Lousy requirements Sometimes it’s the requirements gap, unspecified project or unclear communication between the client, project managers and developers that leads to flawed software. If a client or a manager isn’t specific enough about their product, they shouldn’t expect others to read their minds and do the work they haven’t addressed properly. It is a manager’s job to gather as complete project’s specifications as possible, so the developers don’t need to guess or ask about the specs. 2. Repeatable tasks Doing things over and over again can not only be boring, it can be exhausting. The problem here may be, for example, working on one project for a long time. It may also be a client changing their mind all over again on one feature. Either way, if a developer feels burnt out by the repeatable tasks they are doing, maybe it’s time for you to talk about it with them. If you can, relocate your employee to another project. Sometimes a simple change of the tasks one is working on can be refreshing and keep this employee motivated. At Apptension we use Officevibe for anonymous employee surveys, to measure their satisfaction. 3. Technical debt Technical debt is an effect of using a simple solution without thinking about future scalability of the project. Technical debt In other words: it’s the result of choosing a quick & easy way to do something right now, which is not necessarily the best solution. The reason why developers hate technical debt is simple: Just like it is the case with the financial debt, there will be a moment to “pay it back”, which in development means tackling the same problem again. To fix it, developers often need to rewrite the code to finish “the uncompleted work”. It also causes missing deadlines, as it is hard to estimate how much work is required to pay of the debt. The solution: don’t fall into something because it seems to be easier when you plan it. Think about the best possible solution and execute it once and for all. 4. Not enough or too many tasks Employee underutilization can result in reduced motivation, while too many assignments lead to burnout. Employee underutilization A good company can prevent both by implementing proper resource management. Tools like teamdeck can help maintaining the right resource flow between the projects, and monitoring team’s utilization. teamdeck 5. Interruptions It takes up to 45 minutes for a programmer to get into the so called “zone”, which is a state of the deepest focus, assuring the biggest productivity. Getting out of it is much faster, on the other hand. Sometimes all it takes is a question asked in person or via messengers like Slack. Another form of interruption is context switching. It happens, for example, when a developer is working on several different projects during the day. It might actually cause losing time or project delays for the company, as employees need some time to switch from one project to another one. While managing the project, try to plan every detail of it and avoid interrupting developers during their work. For small interruptions it is common to implement “the headphones rule”, which means that if a developer is wearing them, do not approach them. Important issues regarding the project try to tackle during scrum meetings — that’s what they are for. It will make their work less stressful and more efficient. 6. Unnecessary meetings Not every meeting should actually take place. And certainly you don’t need to have developers involved in the majority of them. There are, however, meetings that require a presence of developers, like sprint plannings, project reviews or retrospectives. Here they can answer technical questions or to comment on the process. Scheduling a meeting, decide if the developers should really be a part of it. If not, they can spend their time more effectively working on a given project. 7. Bad QAs It is important to assure that the code is of high quality, and most developers understand the role of QAs. What programmers hate, are unqualified testers, who interrupt their work instead of improving the code with meaningful reports. Bad QAs are especially annoying and disruptive when they prioritize wrong issues, focus on sitters instead of major issues, or when they leave out key information in bug reports. Good testers, on the other hand, can preserve the quality of the software and help developers in their work, instead of interrupting it. While hiring Quality Assurance team members, do your best to make the best choice, because it will not only result in great quality of the software, but also make the partnership between them and developers less painful. 8. Unclear schedules For every task in software development there should be a clear due time. Milestones help to define when a certain feature should be completed, and when the developers are supposed to deploy the product. An unclear schedule or a lack of it makes it harder for the team to assume the priorities of a project, and to deliver it on time. Another reason for creating better schedules is a team-based nature of developers’ work, often requiring to sync several people to deliver a given feature. Running a project, analyze every stage of it, including scrum meetings, due dates for delivering the features, and shipping date. Then mark them in developers’ calendars. 9. Not including events in sprint planning Consistent project management helps developers to focus on the right tasks at the right time. Including events like Sprint Review, Retrospective, Planning, and Daily Standups in developer’s calendar assures the proper flow of the project. Without doing that, every call for a meeting will be an interruption for a programmer, and you already know that it is both annoying and disruptive for them. 10. Estimating tasks in hours Estimating tasks in hours is often considered as tea-leaf reading. As programming tasks can take different amount of time for various employees, it’s hard to set a clear timeline of finishing them. programming Yet, still many managers ask for time estimates and treat them as deadlines. Although it is important for a company to estimate how long a given project will take, it should be done based on the recent, alike projects, and always assume that it doesn’t mean that a new one will take this exact amount of hours. To improve your estimations, you can consider story points. It is a Scrum concept used to estimate work effort on a story. Story points include the amount of work and its complexity. If a company keeps track on story points, they can better estimate projects based on similar stories from the past. Conclusion Knowing these developers’ pain points, you can keep your employees motivated and focused on the right things. Avoiding them in your company may help in creating a happier workplace for your team. happier workplace And as study shows, happy employee is up to 12% more productive than unhappy one. happy employee is up to 12% more productive Is there anything you’d like to add to this list? Feel free to share it with us in the comments. Is there anything you’d like to add to this list? Feel free to share it with us in the comments. Originally published at blog.apptension.com on April 20, 2017. Originally published at blog.apptension.com blog.apptension.com on April 20, 2017.

10 Things You Can Do Better While Working With Programmers

Overview Helm is the package manager for Kubernetes, like apt, yum, or Homebrew for traditional operating systems. It simplifies the deployment and management of applications on Kubernetes clusters by packaging all necessary components into a single, manageable unit. Why Helm? : Helm packages, known as charts, bundle together all the Kubernetes manifests (like deployments, services, etc.) needed to deploy an application, making the deployment process straightforward and repeatable. Simplifies Kubernetes Deployments : Helm charts can include other charts, allowing complex applications to manage their dependencies effectively. Manages Dependencies : Helm tracks versions of deployments, enabling rollbacks to previous states if needed. Version Control for Deployments What Is It Made of? : A Helm chart is a bundle containing all information necessary to create an instance of a Kubernetes application. It includes resource definitions and configuration files. Chart : The configuration contains customizable parameters that merge with a chart to create a release. These parameters allow the same chart to be used in different environments or configurations. Config : A release is an instance of a chart running in a Kubernetes cluster combined with a specific configuration. Release Helm Architecture Diagram : Helm Client : Local chart development and managing repositories. Chart Development : Manages releases/repos and requests chart installation or release upgrade/uninstallation through Helm Library. Release Management : Helm Library : Handles combining charts and configurations to create releases and installing/upgrading/uninstalling charts. Chart Management : Interfaces with the Kubernetes API server. Interacts with Kubernetes Creating a Chart Creating a Helm chart involves setting up a predefined directory structure with at least two files: for metadata about the chart and for default configuration values. Chart.yaml values.yaml : A basic chart directory will have the following layout: Structure : Contains metadata about the chart such as name, version, and description. Chart.yaml : Specifies default configuration values for the chart. values.yaml : This directory contains template files that generate Kubernetes manifest files based on the values provided. templates/ : Helm uses a templating engine to substitute values in the chart templates, creating Kubernetes manifests tailored to specific deployments. This allows for dynamic adjustment of resources, labels, and configurations without altering the original chart files. Templating Practice : Scenario A startup, "DevOps Solutions" adopts Helm to streamline their Kubernetes deployments. You're a consultant tasked with creating a basic Helm Chart for . It should be customizable for different environments using values. n8n Clone the repo. git clone https://github.com/perplexedyawdie/helm-learn.git Change directory to creating-charts cd helm-learn/creating-charts Spin up the environment using docker-compose. docker compose up -d --build SSH into the container. ubuntu ssh -o StrictHostKeyChecking=no -o NoHostAuthenticationForLocalhost=yes root@localhost -p 2222
# password: test123 Generate a chart directory along with sample files. helm create my-n8n View the structure of the generated directory. tree .

# Output should look similar to this
#`-- my-n8n
#    |-- Chart.yaml
#    |-- charts
#    |-- templates
#    |   |-- NOTES.txt
#    |   |-- _helpers.tpl
#    |   |-- deployment.yaml
#    |   |-- hpa.yaml
#    |   |-- ingress.yaml
#    |   |-- service.yaml
#    |   |-- serviceaccount.yaml
#    |   `-- tests
#    |       `-- test-connection.yaml
#    `-- values.yaml We'll only be using , , and so we can remove the rest since we'll be adding our own manifest files. Chart.yaml values.yaml my-n8n/templates/NOTES.txt my-n8n/templates/_helpers.tpl rm -rf my-n8n/templates/*.yaml my-n8n/templates/tests Update the appVersion in Chart.yaml to "1.27.2" & clear the contents of my-n8n/templates/NOTES.txt file then update with the following. nano my-n8n/Chart.yaml
# appVersion: "1.27.2"

nano my-n8n/templates/NOTES.txt
# Welcome to n8n.
# Wait a few minutes until the status changes to RUNNING.
# After it is ready, access it from: http://localhost:2223 Update the file with the following data. values.yaml # Default values for my-n8n.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: n8nio/n8n
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "1.27.2"

containerPorts:
 - name: http
   port: 5678

service:
  type: NodePort
  port: 30200

livenessProbe:
  httpGet:
    path: /
    port: http
readinessProbe:
  httpGet:
    path: /
    port: http

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

# Additional volumes on the output Deployment definition.
volumes:
- name: n8n-data

persistence:
   claimName: n8n-data

# Additional volumeMounts on the output Deployment definition.
volumeMounts:
 - name: n8n-data
   mountPath: "/home/node/.n8n" Create the , and, files inside the folder. deployment.yaml service.yaml pvc.yaml my-n8n/templates # my-n8n/templates/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: n8n-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Adjust the size as per your requirement # my-n8n/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
      - name: n8n
        image: n8nio/n8n
        ports:
        - name: http        
        - containerPort: 5678
        volumeMounts:
        - name: n8n-data
          mountPath: /home/node/.n8n
      volumes:
      - name: n8n-data
        persistentVolumeClaim:
          claimName: n8n-data # my-n8n/templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: n8n
spec:
  type: NodePort
  ports:
  - port: 5678
    targetPort: 30200
    protocol: TCP
  selector:
    app: n8n Now, let's parameterize these using the go-template language to convert them to templates. Helm will fetch the appropriate values from the file to generate the manifest that will be deployed on K8S. values.yaml # my-n8n/templates/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Values.persistence.claimName }}
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Adjust the size as per your requirement # my-n8n/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name  }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
      - name: n8n
        image: {{ printf "%s:%s" .Values.image.repository .Values.image.tag  }}
        ports:
        {{- range .Values.containerPorts }}        
        - name: {{ .name }}
          containerPort: {{ .port }}
        {{- end }}        
        volumeMounts:
        {{- range .Values.volumeMounts }}
        - name: {{ .name }}
          mountPath: {{ .mountPath }}
        {{- end }}
      volumes:
      {{- range .Values.volumes }}      
      - name: {{ .name }}
        persistentVolumeClaim:
          claimName: {{ $.Values.persistence.claimName }}
      {{- end }} # my-n8n/templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name  }}
spec:
  type: {{ .Values.service.type }}
  ports:
  - port: 5678
    targetPort: 5678
    nodePort: {{ .Values.service.port }}    
    protocol: TCP
  selector:
    app: n8n Ensure that you're in the directory that contains the chart then run the linter. my-n8n helm lint my-n8n Install the chart. helm install my-n8n ./my-n8n Wait until the deployment is complete, you can continually check using the following command. kubectl get all After the status has changed to running, you should be able to access it in your browser from: http://localhost:2223 Recap Great effort! You just learned how to create and configure a Helm chart and then deploy it to a Kubernetes cluster!

Stories, News & Mentions about APPTENSION

Apptension’s Stories on HackerNoon

Apptension's News & Mentions