With numerous advantages over hybrid applications, native apps have ruled the game for so many years. It’s due to the ability to embed features brilliantly, to let the app perform functions in a sublime manner and to embrace the hardware in an ideal manner, which still is beyond hybrid framework’s competence. Cross-platform apps face a crucial choice in their development planning phase – should the application be developed as a native app, or should it be developed as a hybrid or web-based application? This question used to impact the amount of work to be done – namely, until recently, choosing to pursue a native approach for your application meant consigning your development team to simultaneously developing functionality in Objective C/Swift (for iOS) or Java (for Android).

However, this is no longer a consideration when it comes to creating a native app experience. Below we’ll look at using JavaScript to create a cross-platform native app experience by examining React Native and the combination of AngularJS 2 and NativeScript.

Native Apps:

Native apps have a number of advantages over hybrid and HTML 5-based apps. First, native applications are closer to the device’s processor, meaning that on average native code will perform better than equivalent code written for a hybrid framework. Additionally, a native app lets you build in some features that may not be available in your hybrid framework of choice, as you can target specific platforms with specific features, integrating with the hardware on a mobile device can be done right in the same set of source code, rather than having to include a custom module or non-web component in a hybrid app. Couple this with being able to provide an idiomatic user experience for a given device, and choosing to develop a native app becomes a much more compelling choice. By using a framework with a native component, we can further mitigate the costs necessary to develop the app natively.

React Native

In March 2015, Facebook introduced React Native, a tool built to allow developers to use the same base JavaScript code on either iOS or Android. As React was a set of functions with minimal external side effects and a tangential dependency on a DOM, Facebook was able to abstract away the use of a DOM as the primary rendering model into a pattern that allows for the easy substitution of native components instead of web views and HTML components. Thus, using the same code, an application can implement alert windows using UIAlertView on iOS and android.app.AlertDialog on Android, all without having to write any extra native code to support the UI views. Further, the capability of the tool enhanced when it was coupled with React’s speed, which allows you to build a super powerful cross-platform mobile application without making you write the entire code again. Couple this with React’s focus on speed and dirty-rendering, and you can build a blazing-fast cross-platform mobile application with only one code base.

AngularJS 2 + NativeScript

Kendo UI, introduced by the team at Telerik was intended to produce magical stuff (in this case hybrid and HTML5 apps) by blending it with the popular Angular framework. When used for hybrid apps and HTML 5 apps, this created a consistent cross-platform UI experience simply by leveraging the tools provided in the framework. When Telerik began working on NativeScript to provide a true cross-platform native experience, the dependence of Angular 1.x on tight coupling with a DOM for rendering posed problems when attempting to create a native UI map for Angular applications. However, with the advent of Angular 2, this all changed. Angular 2’s looser coupling with a DOM for rendering allowed the developers of NativeScript to perform similar tasks to those performed by Facebook when genericizing React Native – abstracting away view rendering and components so that a DOM was no longer necessary. As a result, Angular 2 integrates easily with NativeScript, allowing you to code your native app in a declarative style that can run on any mobile device platform.

Comparison:

The fundamental difference between the two, lies in the approach they follow in creating mobile applications with the help of the same written code base. Both of them have their advantages and disadvantages, which can’t overlap to dismiss the other. Let’s see what they have to offer. NativeScript takes a holistic approach, working to be a true “Write it once, run it anywhere” framework. This means that a lot of the UI elements used will be decidedly lower-level, as NativeScript is attempting to manage the UI in a transparent and repeatable way between the multiple platforms it supports. Add in the coupling with Angular 2, and you can create cross-platform applications that, through the virtue of Angular’s declarative UI focus, are more conceptually consistent than an application having to interpret between multiple UI paradigms.
On the other side of the debate is React Native, which chooses to embrace – rather than hide – its multi-platform nature. This means that while you can write React Native code in a platform-agnostic manner, you can also get down to the platform-specific UI layer. Stated another way, React’s goal is to abstract the business logic while supporting the differences inherent in UI rendering between each platform, while NativeScript has a focus on creating a singular development experience regardless of platform. Couple this with React’s focus on speed of rendering and execution, and you can easily create performance-focused cross-platform apps that can both run on the same code base, and leverage platform-specific components at will.
Which approach you prefer will ultimately be dependent upon the needs of your application – relatively generic database-powered apps will likely favor NativeScript as the UI is not typically resource-intesive enough to warrant a more platform-focused approach. And even in that case, the use of Angular 2 to drive the application’s architecture negates a lot of the speed benefit that React Native brings to the table. However, the use of Angular 2 with NativeScript requires adopting a traditional Angular architecture for your application’s code, something which React’s library approach doesn’t require. Additionally, with NativeScript being a separate project from Angular 2, this introduces additional dependencies into your application’s pipeline – a problem not as pronounced with React Native, which handles all of the cross-platform functionality in the React framework itself.

Conclusion:

Cross-platform app development has levelled up big time, be it NativeScript app development or React Native app development. Choosing between React Native and a combination of Angular 2 and NativeScript is, in many ways, similar to choosing between React and Angular themselves. React is designed as a blazing-fast lightweight rendering framework to be leveraged within the context of a larger application, and React Native continues this pattern of providing tools instead of patterns. Angular, on the other hand, is an opinionated application development framework that has a “right way” of developing applications in mind, something that the integration of Angular 2 and NativeScript carries further at the slight expense of deeper native device integration.
Thus the choice between the two is largely the same. Is you application focused on complex UI with lots of rendering and custom elements? If so, React Native might be the right choice for you. However, if having a single cross-platform code base with a declarative UI paradigm is more in-line with what you envision for your application’s architecture, then combining Angular 2 and NativeScript can help you realize the same gains you’d see in adopting Angular for a web application, all while maintaining similar development patterns and program architecture.

The post AngularJS VS React Native appeared first on Information Stash.

Many of the 20,000 European workers questioned said a steady stream of emails, messages and notifications kept them from concentrating.

Others said the way their employer deployed technology also stopped them being more productive.

One expert said many staff suffered high levels of technostress.

Read Full Article..

The post Can Technology Be a Distraction? appeared first on Information Stash.

We have gotten a bit carried away with the “entrepreneur” label. Stop it. So many business people are now considered entrepreneurs that it is now easier to figure out who’s who if we just have the non-entrepreneurs raise their hands.

These fundamental definitions and an understanding of their roles will shape the future economy with more force than we may realize.

The entrepreneurs I know…

The fruit of an entrepreneur’s labor is the insatiable need for more, more and more. We can’t stop, and we’re not being hyperbolic when we say that.

Despite the purveying assumption, entrepreneurs are far from fearless. In fact, entrepreneurs are less driven by some moral authority or economic reward and more by the paralyzing fear of failure and the fear of missed opportunity. The true fear is not living up to what the entrepreneur truly believes is the maximized opportunity. This fear of perceived failure is worse than failure itself. Silicon Valley types don’t celebrate failure, because they’re full of themselves; they celebrate it because it’s too hard to look at themselves in the mirror when they fail. The concept of “failing forward” or “you aren’t pushing hard enough if you aren’t failing” are all mantras that make some entrepreneurs too happy to just continue to rinse and repeat the venture life-cycle.

Nonetheless, VC funding pours in, and the population of “entrepreneurs” continues to grow. There’s no shortage of incubators accelerators and free infrastructure (increasing at an average of 50% each year between 2008 and 2014) to support our efforts and feed our endeavors.

X  (previously Google X) says that “instead of a mere 10 percent gain, a moonshot aims for a 10x improvement over what currently exists. The combination of a huge problem, a radical solution to that problem, and the breakthrough technology that just might make that solution possible, is the essence of a moonshot.” What’s missing here is the fact that it takes an entrepreneur’s Draconian thirst to add 10x the ambition with no predefined path, a healthy amount of someone else’s money, and the ability to convince others to join them on the crazy journey.

Those are the entrepreneurs I know. And if nothing else, that description is more accurate than what we’ve been hearing for the past decade. Entrepreneurs don’t dare to be different, they are different.

You might be a small-business owner if…

Small-business owners, on the contrary, build businesses incrementally, bit by bit. They often solve smaller, localized problems with their business and are not looking to radically move the needle. They’re the broad base of employment in America for this reason — they cover a lot of surface area, but aren’t disrupting the status quo, creating entire new fields, or accelerating an entire market forward.

Small-business owners seek lower risk — if it’s a moonshot, it’s by accident. It all tracks back to a timeline that maps far beyond that of entrepreneurs. Small businesses are created with the goal of sustaining a living for the owners and their employees. There’s nothing special or serial about them. These are the people you should ask about work-life balance in an interview.

Furthermore, their products and services often live in the realm of known and established offerings. They live and operate in their local community first and foremost. The local automotive store down the street who’s been there for 50 years? The one who just opened up who will be there for another 50? Those are both small-business owners, tokens of their community who’s definition of winning comes down to how confident they’ll be opening their doors tomorrow. Their broken definition of winning is really about surviving and relative thriving but not truly winning.

The VCs aren’t there to back them or their 15 percent growth models, their march to profitability is a steady cadence of tactical steps in a defined direction with low risk with even lower return. While that direction may change, it’s not at the whim of the market or investor pressure. There is also little pivoting or course correction because small-business owners aren’t looking to discover a new world, but instead just happy with walking the well-established path.

If entrepreneurs are our economy’s moonshots, small business owners are the gravity that keeps our system grounded.

Decoupling is the only way

While both entrepreneurs and small-business owners may have some similar entrepreneurial genes at their core, we can’t ignore the differences between the two that ultimately define their role in our economy. We shouldn’t be angry that everyone isn’t an entrepreneur, but celebrate it. The world and economy needs balance.

Entrepreneurs, at their core, are rare, transformative and risky. They are going to propel the society forward with big leaps of creative disruption. Small-business owners give us a stable base that de-risks the moonshots and protects us from the fallout of failures.

I’m not asking you to make a value judgement of one over the other, but consider this: we’ve been encouraging people to become entrepreneurs for decades and the startup failure rate has reached 90 percent.

We shouldn’t want everyone to be an entrepreneur. It’s not about separating the professionals from the amateurs, either. It’s about responsible approaches to economic growth and societal change.

Let the change agents do the change — real entrepreneurs are well-suited to shape the future. We need small-business owners to anchor our present, and too many of them are being lured away from that important work by an inauthentic, woefully misguided perception of what it means to be an entrepreneur.

We need to strike the right balance of the two, and that starts with vocabulary and perceptions. Imagine if all businesses had a 90 percent failure rate? What if no businesses made giant breakthroughs? When the balance between small business people and entrepreneurs gets out of whack, we can do remarkable harm.

The best way to prevent that is to stop pretending you’re something you’re not.

The post Not Everyone is an Entrepreneur appeared first on Information Stash.

The programming language expertise is an essential part of the development of software. Developers also need to be aware of what’s going on down the stack. Developers who have been around the block several times, however, want you to know that there are a lot of things you should know about writing code for a living that you can’t learn from a college course or a coding academy.

To find out what those things are, we work with a lot of Programmers at the top level. We asked them what they wish they’d known when they first started to code for a living. Whether you’re a recent graduate starting your first developer job, or an older worker who’s transitioned to programming, this will give you a good starting point.

Be Passionate

Love what you are doing, be creative, and do it the best way, better than yesterday.

Programmers are a subset of creators who has the ability of creating the Future and the responsibility of shaping the world said Okpala Izunna, The Lead Software Developer at Information Stash.

In the venture of been passionate, you must love coding in the sense that you have to code clean. No body wants disaster and no professional developer will want to work with a code that is filled with garbage.

Learn about the underlying systems

A big part of software development, of course, is knowing programming languages. But, as several people shared with us, developers also need to know about what’s going on lower down the stack.
Lots of languages abstract away from what is happening at the system level, and that abstraction is useful because it allows developers to be more productive much of the time. But when you hit a roadblock, a really nasty bug, and need a deeper understanding of what’s happening under the hood.

As a developer, chances are you’ll spend a good deal of time working with a fancy IDE or code editor. However, also knowing how to get things done at the command line could occasionally make your life easier.

Your debugger is your friend

A good chunk of your time as a coder will involve tracking down bugs. Learn to use your debugger!! Take that extra day or two to configure it. When you don’t see the expected result, just debug it: set breakpoints, step through your code, and especially 3rd party code. It will save you days of frustration, and even better, you will learn things about coding you can only learn by reading someone else’s code.

Learn to write tests

Some developers feel that unit testing, that is, writing tests to validate that small units of code are doing what they should, is critical. We believe the best bit of advice we’d give someone who wants to learn to program is to learn to write good tests and learn to write your tests really early in the process.

Plan on change and learning new systems

Everyone knows that technology changes quickly these days. That applies not only to our beloved consumer goods, but also to the underlying systems, languages, and tools that programmers use to do their jobs.
We recommends that new coders be prepared for, and stay ahead of, change. Right now, we’re of the mind that you should plan to learn essentially brand new technology stack every ~ 4 years, Good foundational knowledge is always applicable, but the tools and tech you’ll use every day will be completely different every 4 years.

Projects are never written in just one language using one framework anymore… You are never going to work on just one thing in one project, get used to moving from project to project and from language/technology to language/technology.

Play well with others

Despite the stereotypical notion of programmers working alone with their headphones on, developers still have to work other people. Big projects mean lots of moving parts coming together and how they fit together and divide up the problem can create impossible engineering problems if you aren’t careful. Before trying to optimize that one algorithm, work with the team and make sure there isn’t a re-division of the problem that makes each person’s problem simpler. Coding is a team sport!

If you can’t figure it out yourself by re-intuiting the API or debugging, ask for help. Just because you think you’ve written a masterpiece doesn’t mean it isn’t crap or can’t be better. Just like in college, other people in the room have the same questions, or questions only you can answer. Develop a rapport with colleagues. Often just stating the problem aloud enables a open mind moments.
Stepping up to the plate and doing what is asked of you even though it is grunt work will keep you employed as well. But, in that situation, But be careful, you may get stuck doing it all the time.

The post 7 things every new programmer should know Before Coding appeared first on Information Stash.

Despite the fact that OS skills development is nothing new, the subtle changes in business requirements over the years mean the need has progressed beyond foundational skills. Today, companies are looking for people who have more advanced OS skills reflecting a more dynamic, connected business landscape.

While the market for this in South Africa is relatively small when compared to more developed countries, there is certainly significant potential for growth. As demand for OS-based solutions increase here, and on the rest of the continent, so too will the skills requirement.

According to the 2016 Open Source Jobs Report published earlier this month, 65% of hiring managers say OS hiring will increase more than any other part of their business over the next six months, and 79% of hiring managers have increased incentives to hold on to their current OS professionals.

Furthermore, the report found that 58% of hiring managers are seeking DevOps professionals while the need for developers remains the top position on their list at 74%. Perhaps the most telling statistic is the one that shows that 31% of OS professionals say the best thing about their jobs is working on interesting projects, while working on the most cutting-edge technology challenges (18%) and collaborating with a global community (17%) also feature prominently.

This last point indicates just how far OS has come in the business adoption cycle. No longer just limited to core back-end systems, OS provides decision-makers with a way to manipulate the underlying platform to suit more diverse organisational needs. This link between mission-critical platforms and systems are resulting in an increased demand for the associated skills to extract the most value out of the transition.

However, as with any IT component, there are a dizzying array of skills on offer. While much attention is placed on Linux, this is only one part of the OS offering. Companies need to consider the benefits of attracting talent with skills that talk to open customer relationship management, open databases, the open cloud, and even an open management system.

This is resulting in companies increasingly starting to take OS more seriously from a skills perspective. They understand that new requirements mean they have to adopt revised learning programmes that can encompass the likes of online courses, virtual-led classrooms, and self-paced programmes to enhance their existing OS skill set.

It must be remembered that there is no silver bullet approach to take to strengthen OS skills in the organisation. Decision-makers need to be considered and align their development with the company strategy. The most pressing needs are to start taking those first steps to build in-house capacity or to attract more advanced OS talent. The business world of today and the future demands it.

The post The Dire need for Open source skills in Africa appeared first on Information Stash.