开源日报 - Page 105 of 262

开源日报第622期：《幻想命名指南 fantasyname》

27 11 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《幻想命名指南 fantasyname》
今日推荐英文原文：《Perfection Is Holding You Back. Let’s Talk About How To Break Free》

今日推荐开源项目：《幻想命名指南 fantasyname》传送门：GitHub链接
推荐理由：给自己家的孩子起名字从来都是一门学问，从古至今，无数的好坏例子引发的各种惨剧都证明了这一点。这个项目是另一个名字生成项目的开源实现，它们最终的结果都是生成一些奇怪的名字——或者应该称之为幻想风格，你可以通过任意组合它提供的标识符来生成一些难以想象的词语，至于要不要真的把这个诡异的单词拿来扣在某个倒霉孩子的头上……
今日推荐英文原文：《Perfection Is Holding You Back. Let’s Talk About How To Break Free》作者：Costas Andreou
原文链接：https://medium.com/better-programming/perfection-is-holding-you-back-lets-talk-about-how-to-break-free-1fcb86b9ff85
推荐理由：即使现在看起来完美无缺的成果，也迟早都要接受改造的命运
Perfection Is Holding You Back. Let’s Talk About How To Break Free

Inelegant solutions are sometimes OK!

Photo by Jonathan Hoxmark on Unsplash

Perfection is a funny thing. It refers to the idea that something could be so good that it couldn’t possibly be improved any further. Now, we know, however, that is not the case. There will always be room for improvement, whether through incremental or transformational change.
Don’t be afraid of perfection, you’ll never reach it—Salvador Dali
In this article, we are going to explore the concept of incremental change and how this seemingly simple concept can be extended across different areas.
Perfection Is a Process, Not a State
Let us start with a problem all too familiar to those of us in the software industry.

For one reason or another, you’ve inherited a problematic piece of software; it might be a component of a system or a whole application. Regardless of the specifics, the application is ridden with so much technical debt or bad decisions and design that it is technically debt insolvent. That is, there is no point even attempting to bring it back to par; it will be cheaper to start again.

Photo by Christina @ wocintechchat.com on Unsplash

Assuming no cost, resource, and time constraints, no one disagrees that this is exactly what needs to happen. Alas, as it is usually the case, the budget or business drivers are not there. “It’s not that bad,” “it hasn’t caused that many problems this quarter,” and “we will probably just decommission it altogether next year” are some of the common justifications given from the powers above.
Perfection itself is imperfection.—Vladimir Horowitz
Our job as product owners, delivery managers, tech leads, and/or technical architects is to make sure that we reduce the risk we and our applications face. Knowing the perfect solution, dropping the bloody thing, and starting again doesn’t quite get us anywhere. ’Fraid not, however, as the path to perfection is through a careful road map of strategically chosen imperfections.

Imperfect solutions, even seemingly ugly ones, are sometimes needed to get us to our end goal, which will bring us closer to perfection than ever before. Don’t be afraid to pitch your plan and explain why your proposed not so perfect solution is only temporary but will lead to big things.
Define the End Goal
Defining the end goal before you start making any decisions is imperative. It will enable you to focus on what’s important and force you to focus on things that matter.

The end goal, however, should not be the actions to be taken. That is, dropping the application and starting again is not the end goal. Production stability and supportability could be some of the end goals.

Photo by Ian Schneider on Unsplash
Iterative Change
To achieve the end goal, you will need to create a road map on how you will get there. You need to break the plan into distinct milestones. Don’t concern yourself with budgets or how to achieve this at this point. Simply know the broken down states that you need to achieve to get you to the end. It might be things like moving the back end from database A to database B. They’re not holistic solutions, but it will be a move in the right direction.

As long as everything ties back to the overarching plan, the end goal, don’t be afraid to tackle one small piece at a time. Don’t let the imperfections paralyse you and hold you back.

This is incremental change. It can be on a functional level or architectural level; it can even be on a planning level.

Photo by Clark Tibbs on Unsplash
Don’t Be Afraid to Change the Plan
In the same way that sprints, requirements, and development work evolve, so do the plans. With each new bit of information, you’re better equipped to plan ahead. Sometimes that will mean changing the plan; other times it will reinforce the existing one.

In either case, you can always have the best (most perfect?) plan.

This also helps promote an added level of agility, which stops you from sticking to a plan due to previously made decisions. You always make a decision based on the data available at the time. This is often demonstrated by a story of a person going to the cinema. You’ve paid £15 to watch a movie, only to realise 20 minutes in that it is complete rubbish. Do you waste the next two hours staying simply because you’ve already paid for it, or do you accept the sunk cost and move on, taking those two hours back and doing something else?
Closing Thoughts
If there is a single thing you take away from this post, it should be that it’s never all or nothing. In the real world, sometimes things take a while to happen, but with perseverance and a plan, big things can be achieved. It could be that some of the interim stages of the plan include inelegant solutions; that fleeting phase should not be a reason why you do not take that path to success.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第621期：《已有功能 public-apis》

26 11 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《已有功能 public-apis》
今日推荐英文原文：《Is React Overrated?》

今日推荐开源项目：《已有功能 public-apis》传送门：GitHub链接
推荐理由：这个世界上已经有了很多 API，我们只需要去调用他们就好。而这个项目正是对网上关于软件和 web 开发的 API 列表，从沙雕猫猫图到新闻到天气相关的 API 都可以在这个列表里看到，要借用别人家的功能或者数据的话，使用他们提供的 API 自然是最快的选择。
今日推荐英文原文：《Is React Overrated?》作者：Aphinya Dechalert
原文链接：https://medium.com/better-programming/is-react-overrated-c7f8efb75e3e
推荐理由：React 好用是好用，但是实际上它只是一个工具
Is React Overrated?

Or does it actually have some merits, beyond the Facebook association
Early in the year, I gave React an honest try. Coming from an Angular background, I worked on keeping an open mind on the concepts that the library presented.

It was weird at first — coming in from a space where everything has to be structured in a particular way with automated handlers to deal with the flow of data. When it came to data, React had its own thing going on with enforced unidirectional dataflow, no matter what.

But that wasn’t the thing that put me off React — it was the overly defensive aficionados of the community. Perhaps it was my background in Angular, peering in, making comparisons in order to understand how everything worked, that set those (mostly who only know React) to come at me through DMs with stakes and pitchforks.

For a few months, they won and I retreated back to my safe space of Angular. But recently, I’ve had the chance to work with React Native, and here is my honest opinion on the matter.
It’s a Library
React is a library — and libraries are meant to be used in conjunction with one another in order to solve a specific problem. React’s problem-solving skills lie in rendering front end interfaces and managing data that changes frequently.

React’s strength is in the one-way dataflow, ensuring a high level of stability and predictability against mutations and unexpected inheritance.

Another factor that makes React so likable is the way it deals with separation of concerns. It flips the traditional silo approach of separating CSS, JavaScript, and HTML out into separate document files and puts it into a space that allows for it to be handled within a single space.

The traditional method of dealing with SoC as demonstrated through Angular

When something new is required. This structure isn’t just limited to Angular, FYI.

Relationship-based SoC through React.

In theory, a relationship-based separation of concern can be achieved through Angular, but it’s not as intuitive or the default methodology, as it’s being taught in React.

React is only able to achieve this because its rationale is that the code components are kept small enough that their domains and boundaries are easy to detect and understand. But this isn’t a hard rule and the end size is ultimately determined by the developer.
Back to Basics
The popularity of React is mostly due to the lack of a required starting structure. Unlike Angular, where a CLI is required to generate the necessary set up for the framework, React just works with minimal effort.

However, this is the part many comparisons get wrong. React is a library — meaning that it’s small, focused, and targeted. Angular, however, is a framework, meaning that it’s a collection of libraries housed under the same umbrella.

So it’s unfair to say that Angular is bloated based on what it actually is.

A framework determines the way you develop your code and acts as a coordinator for all your associated libraries. It ensures that all the parts work as expected, based on a set of principles or rules. This is necessary because when you have multiple libraries that need to work together, there needs to be some common ground in order for things to run smoothly.

React is not this.

It was never made to be this way — because its sole purpose in life is to render things onto the screen and keep your data connected to the DOM in a clean manner. That’s why state management is delegated out to Redux. That’s why you’ll need to go hunt down other third-party applications if you want to do something other than deal with data and the DOM.

There’s nothing wrong with that either. It’s just the way React works. It’s just the way React was made to be.
Just Because It’s Easy, Doesn’t Mean It’s Better
The Angular vs. React debate is something that seems to be going on for much longer than it should. However, it’s not a matter of what’s intrinsically better — but rather, what fits the situation of your development requirements the best.

The main argument I’ve seen a lot of people fall back on is that React is made by Facebook. But that doesn’t really mean much in the grand scale of everything. Yes, it’s made by Facebook, but React is not the only technology they use. There’s a host of other things in the back end and possibly the front end also.

If we go down the route of who made what, we could say the same for Angular and Google, along with Java and Oracle and .Net and Microsoft.

React is arguably easier than Angular to pick up — especially for new developers without a robust understanding of how clean front end code looks. They may be self-taught, or they may be seasoned engineers transitioning into a different development layer.

Whatever the skill level, React is the equivalent of JavaScript back when it first came out — made to be easy but mostly unmoderated on how you make it work.

The issue that React faces from being a library is that there is no structural enforcement — just syntactical ones. This can result in a deconstructed app with a lack of naming conventions, haphazardous folder structures (if there are any), and redundant files that are bundled in with the production deployment.

In theory, this could be said for anything you end up using if you’re not disciplined in the finer parts of coding that’s not directly code related.
You Still Need to Know Actual JavaScript, Among Other Things
React is JSX — which is a flavor of JavaScript, meaning that you still need to understand how JavaScript actually works as well.

React is probably closer to JavaScript than Angular, which is structured to be more like a traditional programming language with typecasting and controls through TypeScript.

That is why you need to have a solid understanding of how JavaScript works in order to be a productive and effective React developer. Other things you need to be solid on include concepts of states and data flow — because these are the two main things that React deals with and does very well.

Architectural patterns and structures start to become important once you move beyond the starter to-do app. You can’t exactly put your entire cart system with upsells, cross-sells, and historical purchase recommendations on the root folder.

These are some of the things that React tutorials don’t really go into. In fact, most coding tutorials online don’t really talk about architecture or structures at all, along with how to implement the meta stuff in relation to the framework or library.

While no one will actually see any of this once it’s compiled, your fellow developers or the person taking up your code will — and sometimes their sanity depends on how robust your code is against changes.
The Good Parts of React
Being a library means that React is highly portable. You can put it anywhere and it’ll just work — sort of like jQuery and Ajax.

This is particularly useful when it comes to micro front ends and transitional applications that are deeply ingrained inside legacy systems.

Its relationship with React Native is also a point of differentiation and changes the way progressive web apps are made. Unlike other JavaScript-based frameworks, like Ionic, that essentially wrap around your Angular, Vue, or React code in order to generate an app store ready application, React Native takes it one step further and translate your code into the actual native languages required by Apple and Google.

So rather than having a website masquerading as an application, React Native turns it into an actual application — giving it better performance overall and better methods for accessing native features, like maps, compasses, images, and cameras on the device.

The code itself is still mostly React, but a different flavor of React that’s been adapted for mobile devices.
The Annoying Parts of React
As an Angular native diving into the React world, one of the most annoying thing about React is the lack of access to commonly used features and functionalities, such as automated data-binding, and how you can just drop almost any JavaScript-based library in and it’ll play nicely.

Or, just use one of the available libraries that’s already bundled in with Angular. You just have to remember to import it, and voila! Everything is rosy and working.

React, however, relies a lot more on third-party libraries that may or may not play nicely with each other or with React.

There’s also a lack of discussion around component design and component organization in communities — or perhaps I’m just not looking in the right places. As the project grows, you often find yourself pushing your state further up the tree than necessary, resulting in the accidental pollution of the global space.

Redux is often used as the solution to this — but Redux isn’t exactly React and is completely a separate entity from it.
Parting Words
It’s good to note that this is all just opinion, based on my personal experiences with the library so far. In general, the community has been great, except for the few hostiles I’ve encountered that are not as frequent or common in the Angular world.

So is React overrated?

It really depends on which circles of enthusiasts you’re dealing with, and everything has its quirks. React is not the ultimate holy grail of front end solutions, but it does enough to be extremely useful.

As I turn into one of those aging developers that have been around long enough to see projects come and go, I start to approach learning new technologies as updates and upgrades to my current knowledge set — rather than the end-all to everything in existence.

React itself isn’t exactly new either. It’s just another translation of JavaScript, HTML, and CSS bundled together into one space. The same way Angular did it when it first came out, and jQuery before that.

The industry will always be up for the next best thing, but the best thing to do is just learn to code properly and do it well — because it doesn’t matter what framework, library, scaffold, or fancy thing that’s the coolest kid on the block right now. Your quality as a developer is determined by how quickly you can adapt the foundations of good programming to your current requirements and environment.

Thank you for reading.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第620期：《形象生动 algorithm-visualizer》

25 11 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《形象生动 algorithm-visualizer》
今日推荐英文原文：《How To Stop Being Afraid of Technical Interviews》

今日推荐开源项目：《形象生动 algorithm-visualizer》传送门：GitHub链接
推荐理由：这世界上有很多千奇百怪的算法，它们有的用于解决千奇百怪的问题——这两点混在一起，就搞不懂这算法到底在干啥了。这个项目将算法的执行过程可视化，从而降低其学习难度，算法的每一个步骤都将会输出在命令行界面，同时还将显示整个算法操作的数据来让算法的下一步变得容易把握，类似于程序调试器一样的单步前进和后退也能帮助重现一些难以理解的过程。

今日推荐英文原文：《How To Stop Being Afraid of Technical Interviews》作者：Joey Colon
原文链接：https://medium.com/better-programming/how-to-stop-being-afraid-of-technical-interviews-b60b064ff003
推荐理由：对策技术面试提问的六个步骤
How To Stop Being Afraid of Technical Interviews

Learn the UMPIRE technique

Introduction
If you are an up-and-coming developer or a seasoned developer with multiple years of industry experience, you probably have heard or experienced first-hand how nerve-wracking technical interviews can be.

While it was true for myself initially, there were a few things that I did to help cope in these high-pressure situations.

This post and subsequent posts are to not debate whether or not the current way of interviewing is the correct way of conducting interviews for developers. I am treating it as truth and explaining some important concepts on how I played the “game” of interviewing.

In this post, I would like to shed some light on the problem-solving framework I utilized in my interviews. It is best to always have some form of structure when tackling an algorithm question.

The worst possible thing you can ever do in an interview is immediately starting to write code after being presented with the question.

So, if you are not supposed to be coding, then what are you supposed to be doing? This is where UMPIRE comes into play.
UMPIRE
UMPIRE is a problem-solving framework that I picked up this past summer from the CodePath technical interviewing course.

The purpose of UMPIRE is to break down an algorithm question into very specific parts to help better your understanding and solution to the problem.

U — Understanding the problem.

M — Matching the problem.

P — Planning your solution.

I — Implementing your solution.

R — Reviewing your solution.

E — Evaluating your solution.
Understanding the Problem
The first step in the UMPIRE method. You were just asked a question; this is your time to really understand what the interviewer is asking of you.

A common pitfall in the interview is solving the wrong problem. This step is used to eliminate any confusion you may have, assumptions you can make about the problem/edge cases, and most importantly, making your own examples.

In these algorithm problems, you want to create your own examples to not only solidify your understanding of the problem but to see how you would solve the problem — as a human.

Through making your own examples and solving them, you should be able to notice some patterns that your brain is automatically making when solving them by hand.

This is where you need to take note and reverse-engineer how you solved it as a human so that you can write it in code.
Matching the Problem
After creating your own examples, you should have a greater understanding of how you were able to solve it by hand.

This step is used to think about which data structures/algorithms/techniques can I use to help me with this problem? Is the input array sorted? How can we leverage binary search to help us? Linked list problem? Could we maybe use a slow/fast pointer technique here?

These are the questions you should be thinking about out loud. Being able to comment on the tradeoffs between two different approaches provides a good signal to your interviewer, and chances are, if you are talking about the favorable approach, the interviewer will provide signal that you are on the right path.
Planning your Solution
So, you have a solid idea of which data structure you want to use and just hand-solved some of your own examples.

Using the previous information from the last two steps, you will want to start writing out your approach in either plain English or pseudo-code.

Personally, I have had interviews where I had two approaches to solve the problem in mind. If you fall into this case, you want to vocalize your thought process about which tradeoffs you are making for each solution.

By vocalizing this, you convey to the interviewer that you are a calculative thinker and you are open to discussion/collaboration on the type of solution they are wanting. Again, this is the type of signal you want to provide.

When writing up the flow for how my algorithm will work, I will usually leverage helper methods.

For example, if I want to populate a frequency counter, I’ll typically write populateMap(arr, map) in the main flow of my code and note this helper method outside of the main method, all while letting the interviewer know what the method will do.

Interviewers don’t care about watching you write pseudo-code for how to implement a frequency counter, they care about how you will use it to solve the main problem. Don’t trip up on the boring details.

When writing up your approach, you should always use insightful variable names and method names. Having unreadable/irrelevant variable names is most definitely correlated to a bad signal and might even be harder for you to understand if you have to debug through your code in the later steps.

After completing the flow of my algorithm and feeling confident, I will go ahead and ask the interviewer the question: “Is it OK if I code this solution up now?”
Implementing Your Solution
After spending the majority of your time planning your approach, implementing the solution should be relatively trivial.

When I typically enter this step, I like to write my code directly under the respective English comment from the previous step.

In my opinion, keeping your thoughts organized will help keep you focused. As I code, I like to reiterate out loud what I am coding so the interviewer has an easier time to follow along.
Reviewing Your Solution
After writing up the code to your solution, this is where I would take the examples I created from step one and trace through my code with the respective input line-by-line.

This will, again, provide a positive signal to your interviewer that the approach is correct and proves that you have strong tracing skills.

Also, this may be a time where you catch a small syntax bug in your code and allow for any small patch-ups as needed. I typically write a comment above the method with the respective variables and what their value is as I go line-by-line in the program.

There’s no need to make it more stressful on yourself by trying to remember it all in your head.
Evaluating Your Solution
This step is primarily about commenting on what your big-O complexities are.

It is also a chance to reiterate your previous discussion on why you chose to use this particular algorithm. This step can also be used as a way to talk about the potential areas you would have expanded on if you had more time in the interview.
Conclusion
Technical interviewing is hard — there’s no denying that.

Likewise, with many things in life, the skill can be improved upon with consistent practice. If it was easy, everyone would be passing interviews and it would feel a lot less rewarding.

In upcoming posts, I plan on talking about the timeline I used to study. It will include the resources that I used to learn algorithm questions, as well as learning a new language from scratch that I could use to interview with.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第619期：《左右开弓 cypress》

24 11 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《左右开弓 cypress》
今日推荐英文原文：《Ignore the Hype When Learning to Code》

今日推荐开源项目：《左右开弓 cypress》传送门：GitHub链接
推荐理由：页面写完了，该过一圈测试看看有没有漏洞了。这个项目允许你为自己的浏览器页面编写测试，并将测试过程信息等和页面一同显示以方便查看过程。对于原因诡异的预测外行为来说，回放之前进行的一系列操作自然就更容易找到产生错误的那条线，而从这里开始试着编写测试也是一种选择——毕竟在接触到复杂的页面时，编写测试是不可避免的。

今日推荐英文原文：《Ignore the Hype When Learning to Code》作者：Michael Henderson
原文链接：https://medium.com/better-programming/ignore-the-hype-when-learning-to-code-f039198dd4df
推荐理由：学习能力也是能力，基础建设搞好了，万物殊途同归，框架语言等用得到的时候再学也不迟
Ignore the Hype When Learning to Code

Do yourself a favor, and stop being distracted by new frameworks and programming languages
The truth is, I’ve stopped learning a technology dead in my tracks just to jump onto the next latest and greatest thing. For example, I stopped learning Angular to learn React, and I stopped learning ASP.NET 5 to learn ASP.NET Core. I wish I’d have slowed down and learned a technology all the way through before moving on to something else.

The above are two examples of me ruining what I’ve learned in the past just to jump on the latest-and-greatest technology stack. I had no real reason to do this — I just did it because I had seen somewhere online that React was better than Angular.

I was chasing this unreality based on other people’s opinions that one framework or stack was better than another, that companies would use a certain stack over another, and that I wouldn’t be able to get a job if I didn’t keep up with hype train.

This is not true because very rarely will you find a framework or programming language that can’t do what the other can do.

Today, tools are evolving faster than they have ever before. There are new web frameworks, ORMs, programming languages, client-side frameworks, and many more.

As a beginner, you feel pressured to learn as much as you can as fast as you can. This is good — if you do it the right way.

Don’t get it twisted: When I say to learn as much as you can, it means to learn as much as you can about one technology. Don’t learn a little bit about Angular and then move to React. Learn all you can about Angular, then move to React when you feel that you have to.

When I say “learn as fast as you can,” that doesn’t mean learn five things at one time. It merely means to take your time and learn as fast as you can. For me, as fast as I can means a set schedule of learning something for two hours a day. Some people can go faster, but I find that number comfortable for me because I am not exhausting my brain or getting tired of the content.

Most comments you see online about a technology being better than another technology are usually spawned from people that don’t know what they’re talking about. But you do come across some individuals that have good points on why to use a certain technology over another.

These people have usually worked with multiple technologies and have taken the time to learn them each individually. Most of these people have already learned to code.

When you see people say they left Angular to go to React or they left F# to go to C#, it’s mostly because they had a very rare use case that needed to be solved that the other could not handle. Most of those use cases are deep and something that you’re not going to run into for a while.
Just Sit Down and Learn It
Find a technology you’d like to learn, and commit to it without jumping around. If you want to learn Angular, pick a version, set a start date on your calendar, and then commit a set amount of time every week to learn it until you’re close to mastering the technology.

While you’re learning the technology, you’re going to see posts online about React releasing a new version and how it’s better than Angular.

You’ll see the post about how Vue released a new version, and it’s better than React. The cycle goes on like an infinite loop (no pun intended).

Fight the urge to not jump on the hype train … stick with your calendar and the framework/technology that you committed to learning.

If you learn Angular for six months and then drop it and jump to another tech, then you’re losing the value in mastering Angular — and you’re dropping months of hard work and dedication.
When Can I Learn a New One?
You’ll know when it’s time to drop the current technology you’ve been learning to learn another one. There are two main reasons that’ll tell you it’s time to move on to learning a new technology
1. Use case — You may have a use case that the particular technology doesn’t support.
2. Curiosity — You may have an overwhelming curiosity to learn something new.
Before you let the curiosity get the best of you, make sure you understand the big picture. For example, understand code and how it works as well as object-oriented principles before moving on to something else out of curiosity.

You want to master your chosen tech before jumping on board to learn another because most of the tech work in the same way.

When you master Angular (or whichever you choose), then learning React, Vue, or other frameworks will be easier because the high-level concepts are similar.

Depending on what problem the technology is targeting to solve, they all solve that same problem — just in a different way.

The same can be said for programming languages. When you learn C#, then moving to Python will be a lot easier because the same core concepts still apply. You have inheritance, properties, parameters, etc.

Mastering one piece of technology is all about understanding the big picture.

It’s understanding the placement of a compiler, how the components are created, how does the parsers work, etc.

Knowing all of these things will help you become a better programmer with the stack you’ve chosen. When you understand how syntax is compiled and what the compiler is doing, then you’ll have complete control over the language and how to manipulate it to get the result you want.

When you learn how JavaScript frameworks are rendered and interact with the DOM, then you’ll carry that same concept with you throughout your coding journey.
But No One Will Hire Me If I’m Not Using the Latest and Greatest
People who are just learning to program have a huge misconception about what it is companies are looking for. This makes sense because you’re learning to program, you’re not trying to get a job at a Fortune 500 company as the lead software engineer just yet.

The misconception is within the technology stacks that companies use. Just because you see a Stack Overflow survey saying that Angular is the most popular programming language at the moment doesn’t mean that all the successful companies are using it.

To be fair, a lot of companies don’t keep up with the latest and greatest because it’s so expensive to go back and change things. You’re not going to rewrite an entire code base just because of a new release that has a few changes and potentially many bugs.

When you have money on the line — not to mention customers, investors, etc. — you cant rewrite your entire application just to stay up to date with the latest hype. It can cause obvious issues and potential risk to the organization.
What Should I Learn?
Like I said in the beginning, pick a technology, and try to master it. It can be any technology — it doesn’t matter. There will be a place for you in the exciting industry of computer science.

I see job openings all the time that are paying high salaries for Ruby programmers, C++, and even COBOL; those technologies are many years old but are still in demand.

I promise all those technology stacks and frameworks you want to learn will be there after you master what you’d like to master. Just calm down, ignore the hype, and learn something to the fullest extent. So go, pick a technology to learn, and master.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/