开源日报 - Page 112 of 262

开源日报第595期：《举个栗子 tdd-tetris-tutorial》

31 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《举个栗子 tdd-tetris-tutorial》
今日推荐英文原文：《The Tech Interview Prep You Forgot》

今日推荐开源项目：《举个栗子 tdd-tetris-tutorial》传送门：GitHub链接
推荐理由：测试驱动开发，简称 TDD，简单来说就是以通过测试为目的的开发方式（尽管眼光直接放在了结果上，但是这并不代表能够忽视代码质量）。这个项目通过一个简单的俄罗斯方块的例子来介绍 TDD，初学者可以通过编写代码完成预先给出的测试来加深对 TDD 的了解。不过即使学习了新的开发方式，也不要忘记它们只是工具，选择正确的工具使用而不是只吊在一棵树上会更有效率。
今日推荐英文原文：《The Tech Interview Prep You Forgot》作者：Chris Cooney
原文链接：https://medium.com/better-programming/the-tech-interview-prep-you-forgot-2df05998044
推荐理由：面试问题——只不过这次被询问的是面试官那一方
The Tech Interview Prep You Forgot

Be certain this is your perfect company
Interview prep typically refers to the answers we’re going to give. Technical test practice, reading articles about the latest messaging system, or even reading up on body language. But we rarely think long and hard about the questions we’d like to ask.

I’ve interviewed candidates for a while now and I’ll be honest, I don’t remember those that answered questions easily. Their relaxed, casual confidence didn’t stick in my mind. They were qualified and I probably recommended hiring them, but I can’t pick out a single name as I type this.

I’ll tell you who I do remember. I remember the candidates that asked me some tough questions. Individuals that had a self-possessed, candid way about them. It gave them a whole new type of intelligence. They knew what good looked like and they wanted me to pass their test.

Below are some of the best questions I’ve been asked, and some questions I’ve asked myself.

I’ve thought long and hard about these questions and, if you can get these topics discussed, you’ll have a much clearer image of the various facets of a technology company.
Do You Have a Growth and Progression Plan in Place?
Any company that has thought seriously about progression would have come to some quite important features of an effective growth policy.
- Progression needs to be fair and meritocratic.
- People shouldn’t be forced into roles that they aren’t comfortable with.
- We should be aware of what each colleague wants to achieve, whether at or outside of work.
This typically translates into a set of processes that both managers and colleagues can use to develop their career.

Make no mistake, the process can be lightweight. A simple reminder meeting every few months or a couple of measurable objectives here and there. It doesn’t need to be endless form-filling.
What I look for in the answer
A good answer is simple. The interviewer should talk you through their process in a clear and confident manner. I always start by looking for some kind of cadence — every six months, annually, monthly, whatever.

Secondly, I look for some kind of peer review. That is, a manager can’t just keep giving money to their best friend. This helps to maintain a meritocratic policy that doesn’t stifle the growth of a capable engineer, simply because they’re not in the right circles.

Finally, I look for it to be colleague-driven. That is, the company isn’t going to force me down a track I don’t want to go down.

I provide my goals and work with my manager to marry that up with a profitable journey for the company. This usually takes the form of objectives, so pay attention to how those objectives are formed. It’s important.
Red flags
There are a few red flags that can appear. They’re simple to detect and should be cause for further probing. They aren’t instant fails, they’re prompts for investigation.
- The interviewer takes offense that you’re talking about progression before you’ve got the job. This points to a traditional atmosphere where progression is earned with something useless like time-served.
- “We just do it as and when”. Ad-hoc progression can work but often, it translates into insufficient planning being done for progression and thus, a battle every time you want that 1% salary bump. This isn’t a guarantee, just probe a little deeper to find out the truth.
- Awkward silence, followed by exasperated, tired laughter. This is the reddest of red flags — it indicates that it’s absolutely mental and progression is very much an unsolved problem.
How Do You Encourage Consistency Between Teams?
Consistency is all the rage in larger organizations, with drift and poor alignment regularly introducing problems for operational performance.

A company of a sufficient size (>~40 engineers) will have had long, frustrated, and serious talks about how to ensure the same problems aren’t being solved over and over again.
What I look for in an answer
There are a few simple ways that organizations can maintain team autonomy and encourage alignment across products and services. It takes practice and effort, but it’s perfectly possible.
- Engineers are encouraged to assist in multiple teams and cross-pollinate knowledge between those teams.
- In larger organizations, individuals have been hired who encourage teams to talk to one another. Roles such as principal software engineer, architect, or development lead can have this responsibility. If you hear these roles, it’s worth checking.
- Automation. Instead of forcing teams to spend effort doing something a certain way, automate it and remove it as a problem for all future teams. We call this “paved road rather than guard rails”. Make the ideal choice also the easiest choice.
Red flags
There is one monster, mammoth red flag that would be an immediate deal-breaker for me. Any kind of hint that a design is pushed from the top down is a strong no from me.

Ivory towers are not a good look for a tech company

This type of organization will stifle innovation and attempt to reduce their engineers down to typists.

In the past, I’ve inquired further about how they maintain team autonomy, but I’ve never, ever seen a satisfactory answer, when coupled with a top-down information flow.
How Often Do You Have Outages?
You’re going to be told that this company is working on all the latest technology. They’ve got serverless, Kubernetes, jQuery threads that are run on exclusively green energy, across eight cloud providers, and one “on-premises” datacenter in a secret location (usually Milton Keynes).

Don’t be dazzled. You’re getting the sales pitch. What you need is a metric, some kind of clear picture of technological capability within the organization. Outages are very useful for letting you know how their machinery is running.
What I look for in an answer
The absolute ideal answer includes a rate, “3% of our deployments fail” or “we had 99.995% uptime last month”. That lets you know two things.
- If the number is low, you have a clear indication that their software is running smoothly. It might be a madhouse underneath (read: the Amazon model) but things are still running.
- The fact that a number exists at all means they likely have a mechanism in place for measuring and responding to issues. This data-driven mindset indicates an intelligent approach to operations, rather than firefighting without any mind on improvement.
Slightly less ideal but still acceptable would be something like: “We had a couple last month but they were minor and we…”.

This is the human approach to the problem. It’s less data-driven but it reveals their attitude. They’re happy to discuss them.
Red flags
“We never, ever have problems” is a worry for me. Unless it’s a tiny organization with very little code, this is a potential symptom of multiple problems.
- They have no idea how many issues they have, i.e. they aren’t tracking them.
- They’re lying to you and know that the truth would make you head for the hills.
If you suspect that the issue rate is high, this should spark some other questions in your mind.
- What is your testing strategy for your products?
- How do you ensure deployments can be performed independently?
- How do you manage your technical debt?
- How much work in progress (WIP) do you have? How do you manage it?
- How much automation do you have around your deployments?
These sorts of questions should reveal the nature of the disease. In a positive, healthy interview, the conversation will be candid.

The interviewer will be aware of their weaknesses as a company and have no problem discussing them with you. In an unhealthy interview, it will become stand-offish and defensive.
How Do You Regularly Inspect and Improve Your Working Practices?
This question has been a very, very faithful friend for a number of years.

Typically, your interviewer won’t have heard it from many other candidates and they won’t have a pre-canned answer that they can wheel out. Some of the most candid and useful conversations that I’ve ever had in an interview have been in response to this question.
What I look for in an answer
I want to hear three things mentioned before I consider an answer to be satisfactory:
- A mention of feedback loops at multiple levels. Lower-level colleagues can engage in a smaller feedback loop that cascades upwards and impacts larger feedback loops. Anything from running scrum to a suggestions box. Just something that makes it clear that they care about feedback.
- A regular opportunity for genuine introspection. This might be a coffee morning or a “town hall” meeting. It might be “show and tell” meetings on pay-day, or it could be pizza and beers every few months. It doesn’t matter so much, provided the event is inclusive and the event is regular.
- A story of a time when some feedback made its way all the way up to the decider at the top of chain and influenced genuine change in the company. I want to hear a specific example with a tangible output.
Red flags
Look out for a lack of detail. Almost every successful tech environment has a few mechanisms by which they surface improvements. Very, very few just “go with the flow”.

You might be talking to that “one-in-a-million” company that has got improvement baked into its very fabric, but you probably aren’t.

Press for a story, some scrap of history that points to their ability to react to the feedback of even their lowest ranking colleague. It’s important, it’s the difference between leadership and management.

If you can’t get a single story and the company isn’t new, that’s a worrying sign. Either none of their employees are coming up with ideas, those ideas are being stifled or, worst of all, they’re being ignored.

You don’t want to put yourself in any of those environments.
What Do You Normally Look for in a Candidate?
As soon as you ask this, you’re likely to get a technical response. “Great core Java skills and a proven track record of operating production systems”.

Press further, look for more. See what type of person they think will thrive in this environment. You’re looking for two key pieces of information.
- Are they completely insane?
- What kind of environment do they have?
“Yeah, we just want someone to write the code, define the strategy, design the architecture, manage the stakeholders and make us coffee whenever we want it.”
What I look for in an answer
This is a subjective question, so I can’t give you an objective answer.

It comes down to what you want out of a workplace. What I want is simple. An open, collaborative environment where I have the permission to innovate, make mistakes, and learn, without fear of punishment.

To that end, there are some key attributes that I always look for when I am interviewing people.
- The candidate gives and receives feedback without ego.
- They enjoy technology. They might not be the best but they really, genuinely love it and it’s obvious when they speak about it.
Red flags
If I hear any of these phrases, I have to resist the urge to scream.
- “A real go-getter.”
- “Someone who can take the heat.”
- “A hustler.”
You get the picture, right? When people talk like this, it’s because they’re proud of the stress they’ve placed on their colleague’s shoulders.

And that means you too, friend. You’re just a lean piece of meat to them and boy, are they gonna burn you out. Don’t get suckered in to “the hustle”. As the founder of Ruby on Rails likes to say:
“It doesn’t have to be crazy at work”

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第594期：《只是看着 blockrain.js》

30 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《只是看着 blockrain.js》
今日推荐英文原文：《The Lost Art of Vanilla JavaScript》

今日推荐开源项目：《只是看着 blockrain.js》传送门：GitHub链接
推荐理由：这个项目是一个可以在浏览器上运行的俄罗斯方块。作为消遣自己动手定制材质外观或者玩上一会自然挺不错，不过这次兴许有别的消遣方法——这个项目还实现了自动游戏，也就意味着你完全可以看着两个机器人互相竞争（你应该不会想加入这么快节奏的游戏的……）而不需要自己出手，兴许作为等待页面加载时的一种新的打发时间的方式会是个新颖的点子。
今日推荐英文原文：《The Lost Art of Vanilla JavaScript》作者：Danny Moerkerke
原文链接：https://medium.com/better-programming/the-lost-art-of-vanilla-javascript-c11519720244
推荐理由：有了基础才能更好使用那些现成的工具
The Lost Art of Vanilla JavaScript

When programming became gluing libraries together
A couple of months ago, I did a talk on Web Components for a tech company where most attendees had no prior experience with them. It was a very fun and well-received talk that ended with a round of questions from the audience that lasted over half an hour.

Near the end, someone asked me if this meant that we were going back to the days of what he called “jQuery-like spaghetti code,” due to the raw DOM manipulation code I had shown. I could see some others nod in agreement, and this reaction really got me thinking.

Apparently, code that isn’t part of some framework or library but is just what we call “vanilla JavaScript” is perceived as bad and “spaghetti code.” This shouldn’t even come as a surprise.

A whole generation of developers got started using frameworks and starter kits that come with a whole bunch of dependencies out of the box. Just run npm install and tweak the code templates to your needs.

While this can be a good place to start, we do need to realize there’s more to programming than gluing third-party libraries together.
I’m Not Against Dependencies
Let me first make it clear that I don’t advocate against the use of dependencies. In fact, I have quite some experience with multiple front end frameworks.

I do, however, encourage you to ask yourself if you really need these dependencies for your next project before you think about which ones to use.

This is a very important question to ask yourself. It’s a question that I feel is not asked enough, if it’s even asked at all.
The Fallacy of “Don’t Reinvent the Wheel”
You probably heard this many times already. As a developer, you shouldn’t “reinvent the wheel,” but instead, you should use a library that already does what you’re trying to build.

This is good advice when you need a database ORM, for example, because it doesn’t make sense to write that from scratch when there are already good ones available.

The problem is: Where do we draw the line when deciding what to code ourselves and when to use a third-party dependency?

In 2016, the developer of the left-pad package decided to remove all his packages from NPM over a legal issue, and he almost broke the internet by doing so. It was illustrative of how insane the reliance on third-party software has become.

The only job of left-pad is to pad out the left side of a string with zeroes or spaces. The package consists of only a few lines of code, and it can be written by a junior developer in a few lines as well. In fact, it has already been deprecated in favor of the standard String.prototype.padStart(), yet thousands of projects depended on it.

And it gets even worse. The package isarray consists of only four lines of code and checks if a given argument is an array. Of course, this is meant for older browsers that don’t support the native Array.isArray() method, but this could literally be written in one line of code by any developer.

Coding that yourself is not “reinventing the wheel.” There’s really no need to have this as a dependency in your project.
We Have No Idea What We’re Using
Still, people argue that it’s better to use already available third-party modules — even when they’re very small — because these have been “battle-tested” and are “proved solutions.”

The question is: Are you sure?

Do you know that a dependency is a well-tested and proven solution, or do you just assume it is?

Do you really know all the stuff that’s in your node_modules folder?

I don’t, and probably nobody does. In all honesty, you don’t have to, but at least you should think about what to install as a dependency and what to code yourself.

Do you really need a bloated library to make simple HTTP calls when there’s already fetch in every modern browser? Or a large date parsing library that you can write yourself in a few lines of code and that does only what you really need?

It seems like a whole generation of developers are too insecure to write and use their own code, and instead, they resort to gluing libraries together that they assume to be well-tested and bug-free.

But this is a false sense of security.
How Did We Get So Insecure?
Why are we as developers so afraid to trust our own code and rather use other people’s code we think is better and more secure?

After all, these people publishing their open-source code on Github are also developers, just like us. They’re not perfect either, and they might also write code that has bugs. Yet we choose to trust in them and not ourselves.

I understand that you don’t want to write a library like RxJS or React yourself, for example. These are large libraries that have been around for years, have many contributors, and are well-tested. I wouldn’t recommend reimplementing these unless you want to learn from it.

But for smaller functionality that you can easily code yourself and fully adapt to your own needs, I would recommend to write this yourself. At least you can easily modify and fix it when needed.

I guess the insecurity in developers to write their own code comes from years of using libraries and frameworks that have hidden the native JavaScript platform from us. This already started with jQuery and got worse with the emerging of frameworks like Angular and React.

These are abstractions that, by their nature, are perceived as complex. Because of that, developers tend to use these as black boxes.

Again, I’m not anti-framework and I do see the value they bring. But now, it seems like there’s a whole generation of developers that only know how to program using a framework and have little-to-no knowledge of the underlying platform. They wouldn’t know how to work with the raw DOM because they have hardly been exposed to it, if ever.

I’ve been involved in a couple of evergreen projects where the first question was which framework we should use, not if we even should use one. The default assumption was that a framework was needed, and the main argument was that a framework would provide everything we needed and we shouldn’t reinvent the wheel.

The irony is that many of these people didn’t have enough knowledge of the native platform to tell whether or not the chosen framework was a good choice in the first place.

It’s understandable that the complexity of these frameworks is intimidating, especially for beginning developers. They’ll tend to use them as black boxes without understanding how they work internally.

Frameworks don’t encourage this either since their job is to make programming easier to get started with by hiding low-level details and APIs.

This creates dependence on the framework, which in turn doesn’t help in giving developers the confidence to code things themselves.
Using Dependencies Is Outsourcing Your Business
When you’re using a dependency in your app, you’re basically outsourcing that part to some other developer, and so you better be sure that person is doing a good job.

If you have a business and you outsource customer service to some other company, you’d be in big trouble if they’d mess it up. What if they have a different idea of what good customer service is?

You probably wouldn’t let that happen, and you should treat the dependencies in your app in the same way. That doesn’t mean you need to read all of your dependencies’ source code, but at least you should have a solid idea of how it works.
Know the Foundation
But to be able to do that, you should first have a solid understanding of programming in vanilla JavaScript, since that’s the foundation of it all.

Front end frameworks definitely bring value, but also complexity and overhead. I’ve been through the pain of learning and implementing several frameworks, and I can tell you that you need to make sure the effort is worth it.

There’s no reason not to use the native platform, and you’ll be surprised to see what it has to offer nowadays.

Don’t just parrot the people saying you shouldn’t reinvent the wheel. Learn the foundation first, and then decide whether or not you really need that library or framework.

You’ll be a better developer for it.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第593期：《舍近求远 img2css》

29 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《舍近求远 img2css》
今日推荐英文原文：《4 ways developers can have a say in what agile looks like》

今日推荐开源项目：《舍近求远 img2css》传送门：GitHub链接
推荐理由：如何在一个 HTML 页面中插入一张图片呢？除了 img 之外，还有一些令人不解的方式，比如说拿 css 把这张图强行画出来。这个项目就提供了这样的转换功能：上传一张图片，它会用 css 将其画出来，结果实际上意外的还挺像的，颜色形状都不算太偏，唯一的问题就是：生成的代码占的空间能达到原来图像大小的十倍左右……
今日推荐英文原文：《4 ways developers can have a say in what agile looks like》作者：Clement Verna
原文链接：https://opensource.com/article/19/10/ways-developers-what-agile
推荐理由：介绍敏捷开发的好处
4 ways developers can have a say in what agile looks like

How agile is implemented—versus imposed—plays a big role in what developers gain from it.
Agile has become the default way of developing software; sometimes, it seems like every organization is doing (or wants to do) agile. But, instead of trying to change their culture to become agile, many companies try to impose frameworks like scrum onto developers, looking for a magic recipe to increase productivity. This has unfortunately created some bad experiences and leads developers to feel like agile is something they would rather avoid. This is a shame because, when it’s done correctly, developers and their projects benefit from becoming involved in it. Here are four reasons why.
Agile, back to the basics
The first way for developers to be unafraid of agile is to go back to its basics and remember what agile is really about. Many people see agile as a synonym for scrum, kanban, story points, or daily stand-ups. While these are important parts of the agile umbrella, this perception takes people away from the original spirit of agile.

Going back to agile’s origins means looking at the Agile Manifesto, and what I believe is its most important part, the introduction:
We are uncovering better ways of developing software by doing it and helping others do it.
I’m a believer in continuous improvement, and this sentence resonates with me. It emphasizes the importance of having a growth mindset while being a part of an agile team. In fact, I think this outlook is a solution to most of the problems a team may face when adopting agile.

Scrum is not working for your team? Right, let’s discover a better way of organizing it. You are working in a distributed team across multiple timezones, and having a daily standup is not ideal? No problem, let’s find a better way to communicate and share information.

Agile is all about flexibility and being able to adapt to change, so be open-minded and creative to discover better ways of collaborating and developing software.
Agile metrics as a way to improve, not control
Indeed, agile is about adopting and embracing change. Metrics play an important part in this process, as they help the team determine if it is heading in the right direction. As an agile developer, you want metrics to provide the data your team needs to support its decisions, including whether it should change directions. This process of learning from facts and experience is known as empiricism, and it is well-illustrated by the three pillars of agile.

Unfortunately, in most of the teams I’ve worked with, metrics were used by project management as an indicator of the team’s performance, which causes people on the team to be afraid of implementing changes or to cut corners to meet expectations.

In order to avoid those outcomes, developers need to be in control of their team’s metrics. They need to know exactly what is measured and, most importantly, why it’s being measured. Once the team has a good understanding of those factors, it will be easier for them to try new practices and measure their impact.

Rather than using metrics to measure your team’s performance, engage with management to find a better way to define what success means to your team.
Developer power is in the team
As a member of an agile team, you have more power than you think to help build a team that has a great impact. The Toyota Production System recognized this long ago. Indeed, Toyota considered that employees, not processes, were the key to building great products.

This means that, even if a team uses the best process possible, if the people on the team are not comfortable working with each other, there is a high chance that the team will fail. As a developer, invest time to build trust inside your team and to understand what motivates its members.

If you are curious about how to do this, I recommend reading Alexis Monville’s book Changing Your Team from the Inside.
Making developer work visible
A big part of any agile methodology is to make information and work visible; this is often referred to as an information radiator. In his book Teams of Teams, Gen. Stanley McChrystal explains how the US Army had to transform itself from an organization that was optimized on productivity to one optimized to adapt. What we learn from his book is that the world in which we live has changed. The problem of becoming more productive was mostly solved at the end of the 20th century, and the challenge that companies now face is how to adapt to a world in constant evolution.

I particularly like Gen. McChrystal’s explanation of how he created a powerful information radiator. When he took charge of the Joint Special Operations Command, Gen. McChrystal began holding a daily call with his high commanders to discuss and plan future operations. He soon realized that this was not optimal and instead started running 90-minute briefings every morning for 7,000 people around the world. This allowed every task force to acquire the knowledge necessary to accomplish their missions and made them aware of other task forces’ assignments and situations. Gen. McChrystal refers to this as “shared consciousness.”

So, as a developer, how can you help build a shared consciousness in your team? Start by simply sharing what you are working on and/or plan to work on and get curious about what your colleagues are doing.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第592期：《自己画表情 emojidiv》

28 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《自己画表情 emojidiv》
今日推荐英文原文：《Things You Should Know If You Want to Become a Machine Learning Engineer》

今日推荐开源项目：《自己画表情 emojidiv》传送门：GitHub链接
推荐理由：世界上有非常多的表情供我们用于日常聊天中，不过即使有了现成了，自己画一个也一样是很有意思的事情。这个项目收集了世界上网友们自己画的表情——限制是只能用 HTML 和 CSS。如果想为 GitHub 上某个项目贡献一份力但是心有余力不足的话，这个项目就是个很好的开始，你可以在表情上运用所学与创意来制造出一些万万没想到的玩意来。

今日推荐英文原文：《Things You Should Know If You Want to Become a Machine Learning Engineer》作者：Samantha
原文链接：https://opensourceforu.com/2019/10/things-you-should-know-if-you-want-to-become-a-machine-learning-engineer/
推荐理由：成为机器学习工程师需要的技能
Things You Should Know If You Want to Become a Machine Learning Engineer
Machine learning is the next big thing in the market. Have you seen machines that do activities without any human involvement? This is what machine learning engineers do. They develop machines and systems which can learn and apply knowledge.
How is artificial intelligence changing the job scenario for machine learning engineers?
Artificial intelligence and machine learning have been successful in touching almost every aspect of our daily life. It may be the voice-activated virtual assistants like Siri and Alexa, or Predictive technologies used by companies like Netflix and Amazon for a better understanding of the customers.

Artificial intelligence makes the computer do the tasks which earlier needed human intelligence and machine learning is about building the algorithm for the machines which helps them to identify patterns and thus give a better insight into the data. Countries around the world are continuously working on strategies and initiatives to guide the development of artificial intelligence.

Lately, organizations from almost every sector are investing in AI tools and techniques, thus boosting their companies. Currently, AI investments are being dominated by large tech companies like Baidu, Microsoft, Google, Apple, Facebook, and so on. And almost 10%-30% of non-tech companies are adopting artificial intelligence, depending upon their industry.

There has been considerable advancement in the automobile industry with the implementation of Artificial intelligence with vehicles. Self-driving cars were something impossible without IoT working closely with AI. Then there is the Facial recognition feature by Google, which helps to identify a person using digital images or patterns. These technologies are changing the way people have expected their life to be.

As per a recent study, Artificial intelligence will be creating almost 58 million new jobs by 2022, giving a major shift in quality, location, and permanency the new jobs. BY 2025 machines will be taking over the work tasks that are being performed by humans by almost 71%, with the human workforce focusing more on productive tasks. This creates the need for reskilling and upskilling of the current workforce.

In a current report, the top decision-makers of IT/ITES observed that Machine learning and other AI-powered solutions would play a major role in shaping future workplaces. With the latest technological advancements, the tech companies are on the lookout for talents equipped with a better understanding of these technologies.

Here are some of the skills needed for becoming a machine learning engineer.
Programming skills:
Machine learning calls for a stronghold over programming and software development skills. It’s all about creating dynamic algorithms. Being clear with the fundamentals of analysis and design can be an added advantage for you. Here are the skills that you should be acquainted with:
Fundamentals of Programming and CS:
Machine learning involves computation of huge sets of data which requires knowledge on the fundamentals concepts such as computer architecture, data structures, algorithms, etc. The basics of stacks, b-trees, sort logos, or the parallel programming problems come in handy when we talk about the fundamentals.
Software design:
Being a machine learning engineer, you will be creating algorithms and systems to integrate with existing ecosystems other software components. And for this, a stronghold over in Application Programming Interfaces (APIs) like web API’s, static and dynamic libraries, etc. are essential for sustenance in the future.
Programming languages:
Machine learning is known for its versatility and is not bound to any specific language. All it needs is the required components and features, and you can virtually use any language if it satisfies the above condition. ML libraries have got different programming languages, and each language can be used for a different task.
Python:
One of the popular languages used among machine learning engineers is Python. It has got many useful libraries like NumPy, SciPy, and Pandals which help in the efficient processing of data and better scientific computing. It has got some specialized libraries like Scikit-learn, Theano, and TensorFlow, which allow learning algorithms using different computing platforms.
R Language:
Developed by Ross Ihaka and Robert Gentleman, this one of the best languages used for machine learning tasks. Coming with a large number of algorithms and statistical models, it is specially tailored for data mining and statistical computing.
C/C++:
C/C++ use is pretty much lower when we talk about the programming languages needed for machine learning. But it cannot be as it is used to program the infrastructure and mechanics of machine learning. In fact, a number of ML libraries are actually developed in C/C++ and wrapped around with API calls to make it available for other languages.

Although the language is a bit different from traditional languages, it is not difficult to learn.
Basic skills needed:
Machine learning is a combination of math, data science, and software engineering. And no matter how many certifications you have got, but you should be well acquainted with these basic skills to be master in your domain:
Data modeling:
Data modeling is a process used to estimate the structure of a dataset, for finding patterns and at times when data is nonexistent. In machine learning, we have to analyze unstructured data, which relies wholly on data modeling. Data modeling and evaluation concepts are needed for creating sound algorithms.
Statistics:
Statistics is mainly the creation of models from data. Most of the machine learning algorithms are building upon statistical models. It has got various other branches which are also used in the process like analysis of variance and hypothesis testing.

Along with these two, there is one more basic skill, which is of utmost importance – Probability. The principles of probability and its derivative techniques like Markov Decision Processes and Bayes Nets help in dealing with the uncertainties and make reliable predictions.

These are many skills which are needed to become a machine learning engineer, and many institutes provide professional Machine learning certification course. They are playing a major role in the rise of AI and efficient machine learning engineers by guiding the participants through the latest advancements and technical approaches in artificial intelligence technologies.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/