开源日报 - Page 175 of 262

2019年2月23日：开源日报第345期

23 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《每日任务 Daily-Interview-Question》
今日推荐英文原文：《What is DevOps ?》

今日推荐开源项目：《每日任务 Daily-Interview-Question》传送门：GitHub链接
推荐理由：这个项目上每天会更新一道关于前端的大厂面试题。在更新之后大家就可以去 issue 上提供自己的答案，在之后答案会公布出来以供参考，不管是作为面试前的准备还是用来考验一下自己的水平都是一个不错的选择，如果自己有过这样的面试经验的话，作者也欢迎面试题的 pull request。
今日推荐英文原文：《What is DevOps ?》作者：myTectra
原文链接：https://medium.com/@mytectra/what-is-devops-2c2257a32d99
推荐理由：相信大家或多或少都听过 DevOps 这个词，这实际上指的是一种工作运行的方式
What is DevOps ?
In earlier days, solutions were associated with getting the technology right. The key was technology, the solution was technology and the business expected and paid for technology. Times have changed. Well, at least for those of us taking notice. Today technology is hardly ever a significant problem. Technically, we have a less complicated world. Over the years we have come to understand that technology is basically an arrangement of Processing, Memory, Networking and Storage. We have mastered utilization by using virtualization. We understand horizontal scaling is ‘better’ than vertical scaling and that we can deliver the PMNS more easily in converged and hyperconverged products that also contain the software solution. We have automated many of the key activities to enable reduction in time and costs.

The Cloud paradigm came along and made life easier by helping us to become Service Brokers rather than server admins or network engineers. To the customer we are now Service Brokers; well, we should be. We should be experiencing shorter procurement cycles given that applications and services (the solutions) are delivered from a Service Catalog. Although this can be true in the Public Cloud deployment model and the Software as a Service (SaaS) delivery model, when it comes to Private Cloud procurement we still seem to be stuck in the past and suffer unnecessary delays. Even as Public Cloud services are taken up by more and more businesses the activity of getting the servers, applications and services ‘up there’ still makes for hard going. All the work that is required to design and deliver a Public Cloud hosted environment is still steeped in old-fashioned working practices.

Despite all this change and learning, solution design and implementation is still a thorny job and produces mountains of documentation (some needed, some pointless), endless Gant charts and interminable meetings trying to get the solution in place and delivered. Why is this?
Application Development and Delivery
Application developers use to live in a world of their own. To some extent that is still true. Application development companies don’t usually have network engineers, technical architects and storage SMEs sitting in on the early morning scrums. Applications are developed in isolation and separate from the technical solutions that will need to be created to host, resource and support the application.

In most cases an application is developed for one of two reasons. To provide a solution for an external customer or to provide an application for the business with which it can make money. For instance, a company needs to pay salaries. To do that it needs an application that can pay the salaries, calculate tax and pension information and enter data into a database and then print a payslip all in accordance with the legal framework set out in the Revenue Services ‘rules of engagement’. An application development company will take on that challenge and through a series of iterations it will deliver an application that meets all of the customer and legislative requirements. For a business that wants to make money from an application the scenario is very similar to that for an external customer. The difference is financial in that the business has to justify the cost of having developers on staff creating the application. That cost is set against a forecast of income from the eventual deployment of the application as a service for the business.

In both of the examples there are constants that can make for hard going. In the same way that technical solutions are affected by people, process and politics, so application development is affected by an isolationist practice. Why is this?
Why Is This?
Across all IT from datacenter infrastructure to applications to cloud there is one problem that affects the smooth, joined-up running of a project and that is ‘silos of activity’.

The silo has long been the black mark of IT. We became so used to operating in silos that we didn’t question whether such an arrangement was productive and cost effective. In fact, even now, the majority of IT organizations operate using silos. Solutioning and development in isolation.

Solution design and application development saw the arrival of Lean and Agile as a really effective way to operate and yet, silos remained. Companies operated Agile but, kept the silo way of doing things. Strange when you think about it. Agile means flexible and able to change without trauma. Silo is a ‘pit’ with high sides that makes change very difficult. So, in essence, Agile and silo worked together and made change difficult. Still does.
Silo
Here is a real-world example of a silo-based traditional IT environment where an application is to be developed and deployed. The process may differ slightly in some companies and the job titles may not be the same but, this has been my experience working for several large IT corporations and it is recognisable as a fairly common procedure.

The Application Developer creates an application from a concept or from a request. A Technical Services (TS) Architect is asked to create a High Level Design (HLD) for the application infrastructure. The TS Architect passes the HLD to the Project Architect to review the design. The Project Architect passes the final HLD back to the TS Architect. The TS Architect explains the design to the application developer and covers off any items that are likely to compromise the application. This is usually done in isolation from other experts. The HLD is signed off buy someone or other and the Project Architect sets about carrying out a due-diligence activity prior to creating the Low Level Design (LLD or Build Doc) for the application infrastructure. The Project Architect has to visit various Subject Matter Experts (SMEs) for Compute, Network, Storage and Disaster Recovery (DR) to find out what technologies and requirements will need to be in the LLD. Details around protocols, routing, security and firewall rules can be complex and can negatively affect the application if not carefully planned. To get this right a Business Impact Analysis expert needs to be consulted to make sure that security and compliance problems, if they exist, can be dealt with or mitigated. Most applications are deployed to virtual infrastructures which require the involvement of virtualization experts to aid provisioning and automation technologies. All in all, the Project Architect has to consult with many different silos of technology/experts. In the course of this activity the Architect has to constantly return to the application developer to check that what is being planned for the infrastructure is not going to ‘damage’ the application design and make the application ineffective when deployed. Finally, the Service Wrap needs to be put in place to support the application and to meet the non-functional requirements in the Service Level Agreements (SLAs). There could easily be twenty people involved in this process. I haven’t included test and development as this usually waits until the end of the main process along with User Acceptance Testing (UAT). Sometimes there is a separate team that handles this part, sometimes it’s carried out by Operations. Application design also includes the dependency tiers that provide the middleware and database layers. It could be that many more people will need to be involved when those services are included. What is true is that each SME is part of a silo. The project has to consult all these silos. Some are helpful, some are not and there are lots of reasons why No! can be the answer to all questions and suggested solutions.

All the silos and all the people involved make the whole project slow and costly. The analogy is the game of Snakes and Ladders.
DevOps
Although the above example is somewhat crude it is a fair assessment of what application development can be like end-to-end. Everyone in the industry knows that this is the ‘normal’ state of affairs and accept that it is less than perfect. DevOps has begun to appear on the scene as the answer to the traditional silo approach. DevOps attempts to remove the silos and replace them with a collaborative and inclusive activity that is the Project. Application Development and Solution Design benefit from DevOps principles.

What needs to be done to remove silos:
- Change the working culture
- Remove the walls between teams (and you remove the silos) Keys:
- Communication, Collaboration, Integration and Information Sharing
- Easy to say and hard to do.
Most SMEs like to keep their information to themselves. Not true of all but, of many. It’s part of the traditional culture that has developed over many years. Working practices have made change difficult. Management of change is one of the most challenging tasks any company can embark on. Resistance will be resilient as it is important that people give up something to gain something. Making it clear what the gains are is imperative. People will change their attitudes and behaviours but, you have to give them really good reasons to do so. I’ve found that running multi-discipline workshops for the SMEs has proven an effective method of encouraging information-sharing and the breaking down of those ‘pit-walls’.

Explaining to the teams what DevOps is and what it is supposed to achieve is the first part of the educational process. The second is what needs to be done.

State specific, measurable objectives:
- Implement an organization structure that is ‘flat’. If we espouse horizontal scaling, why not horizontal organizations?
- Each App-Dev or Solution-Dev is a project and the team is end-to-end across the disciplines
- Implement ongoing informational exchange and reviews
- Make sure that everyone signs up to DevOps and understands the paradigm
What is DevOps
Just like the Cloud paradigm it is simply another way of doing something. Like Cloud it has different definitions depending on to whom you are speaking at the time.

Wikipedia states: Because DevOps is a cultural shift and collaboration between development and operations, there is no single DevOps tool, rather a set or “toolchain” consisting of multiple tools. Generally, DevOps tools fit into one or more categories, which is reflective of the software development and delivery process.

I don’t think that this is all DevOps is. The inference is that DevOps is concerned only with application development and operations. I do not believe that. I believe that DevOps is a paradigm and that like other IT ‘standards’ and paradigms it is relevant to all IT and not just applications. By removing the partitions between each practice in the chain and having all the key players involved from day one, as part of an inclusive and collaborative team, the cycle of application development and solution design becomes a continuous process that doesn’t have to divert to consult each required expert. No-one needs to throw a document over the wall to the next crew. Each document is written within the collaboration process and this has to make the document more relevant and powerful. Imagine that the project team is always in the same room from concept to deployment and each expert is always available to comment on and add to each step of that project. How much better than the traditional method where it can take days to get an answer to a simple question, or to even find the right person to ask.

The mantra is: Develop, Test, Deploy, Monitor, Feedback and so on. This sounds application-orientated. In fact, it can apply to the development of any IT solution. Like ITIL, TOGAF and the Seven Layer Reference Model it can be applied to any and all IT activities from development right through to support services. DevOps puts us all on the same page from the start to the finish.

Don’t allow your company to implement DevOps in isolation and only as a framework for application development. To do that would be to create another silo. Use it for every project and as the default culture for all your teams whether or not they are developers, engineers, architects or operations. And, finally, don’t complicate it. DevOps doesn’t need deep and profound definitions or long and tedious conversations about what it is and how to implement it. Just do it.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月22日：开源日报第344期

22 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《Surprise Mind-Expanding-Books》
今日推荐英文原文：《Software Architecture and Agile. Are they both really compatible?》

今日推荐开源项目：《Surprise Mind-Expanding-Books》传送门：GitHub链接
推荐理由：会让人大吃一惊的书籍合集，包括发行将近 20 年的老书和最近几年的新书，内容涵盖了相当多的方面——政治历史，写作和语言等等。如果你希望寻找一些关于自己感兴趣方面的书籍的话，这个项目兴许可以帮上你的忙，项目中也提供了它们的评分以供参考。
今日推荐英文原文：《Software Architecture and Agile. Are they both really compatible?》作者：Miguel Arlandy
原文链接：https://medium.com/@m_arlandy/software-architecture-and-agile-are-they-both-really-compatible-c1eef0afcbb1
推荐理由：软件架构和敏捷开发如何协调在一起
Software Architecture and Agile. Are they both really compatible?
In this article, we will discuss how Software Architecture and Agile Methods can be used together to make the most of them.
What is Software Architecture?
There are tons of different definitions to describe what Software Architecture is. This one particularly appeals to me:

“Group of principles and constraints about how software solutions have to be built within a given boundary (usually an enterprise)”

Some examples of principles and constraints would be:
- Only programming languages based on the JVM
- Synchronous communication among components through REST APIs. Each API specification must always be written in Swagger.
- Asynchronous communication using the corporate message broker (i.e: RabbitMQ)
- Tracking (audit, logs) through ELK. Every message must have a specific format.
Ideally, this group of principles and restrictions will be influenced by the business that it supports. So it’s likely building software for a nuclear power station will differ greatly to building software for a marketing company.

Moreover, as with any software, quality attributes (non-functional requirements) must be included:
- High availability
- Security
- Performance
- Modifiability
- Testability
- Etc…
The balance of these quality attributes should be set up in a way that the build solution demands. Building a small web application which will be used by just two users inside a LAN for query data clearly won’t be the same as a system that will manage clinical history (SECURITY), or software to control rail traffic (PERFORMANCE, AVAILABILITY, ROBUSTNESS). Quality attributes will obviously vary.

Therefore, architecting is applying these principles, functional and non-functional requirements to build a technical solution: components, interfaces, relationships, structure, and so on…

Martin Fowler describes Software Architecture as the decisions which are hard to change. A simple but brilliant quote.
Why Software Architecture?
As the number of software solutions grows, a degree of homogenization among these solutions is required. In most cases, this process has economic implications. Saving costs directly or indirectly.

Let’s go back to the previous part where we assumed that in an enterprise (or a subset in there) only JVM languages can be used. What leads a group of architects (or whoever) to make such a decision? Why do they restrict software development to a specific language? Furthermore, if we wanted our component communications to be done through REST APIs, the programming language won’t be a barrier because the service API itself will abstract the relationship to the language used to implement each component: high cohesion and low coupling.

The reasons, as we previously mentioned, used to be economical. What will happen if the whole platform would be built using seven different languages? Which skills a developer for such a platform should have? What will happen if we want to hire enterprise support for each language? How are these things run in production: monitoring, upgrading, infrastructure, and so on…? What will happen if we want to provide a corporate software framework to develop different components? Do we have to implement it in seven different languages? Those are just some of the problems that would arise without this constraint. Therefore, what could initially be considered as a limitation (using merely one programming language), becomes a way of saving costs in the future. Obviously, these sorts of constraints lead to drawbacks that have to be analyzed considering the enterprise’s culture.

So, Software Architecture will be worthy if it satisfies the architectural drivers (principles and constraints), providing the necessary foundations for the rest of the code, and will work as the platform for solving the underlying business problem.
What is Agile?
In essence, Agile is about moving fast and embracing change. It is continuous improvement. Agile is giving a good solution with a high degree of quality in a short period of time. It’s about removing waste (everything that is not worthy).

There are different agile methods like Scrum based around autonomous and self-organized teams. Scrum relies on an iterative (repeated cyclically, normally in short intervals) and incremental (gives new functionality) process.

But, how do these autonomous and fast-paced teams match with a group of principles and restrictions to build a software solution? Will the process of “architecting” a solution delay the continuous value delivery? Maybe the key point is, how much time do we have to spend on “architecting” in each iteration?

Definitely, there’s no easy and specific answer to this question. The most sensible answer would be “just enough”. The minimum amount of architecture to fulfill the principles, vision, constraints to build a solution. Once again, how much is “just enough”?

It depends on the project/product that is to be built. If we are in a very chaotic project with lots of changes probably the amount of upfront architecture would be lower than more stable projects where doing some design in advance would be easier. As a rule, it would be recommended to do some upfront design at the beginning of the project (Sprint Zero?) and before the first iteration. Besides, we should include an “Architecture review” as part of the Definition of Done (DoD) in each user story. Of course within the Sprint Planning, this fact has to be taken into account. It would be worthwhile if at least one of the team members (if not all of them) will be accountable to ensure both product development and Architecture are aligned.

If we just hope that the Software Architecture will simply emerge we could end up in a series of “refactoring sprints” because of the lack of upfront design, especially with large and complex projects. As Martin Fowler said, Architecture is a group of relevant decisions which are hard to change. Neglect with such decisions would lead to delays and huge technical debt, which is contradictory to Agile philosophy.
How much Software Architecture do we need?
Probably the answer may be something like, the minimum amount to fulfill the principles, constraints, functional and non-functional requirements as well as supply the basis to build a solution.

Let’s look at some different scenarios. If we were to build a solution to collect and querying data related to our customers’ clinical history, probably the Software Architecture will be strongly shaped by lots of politics about how to access data, obfuscation, certificates, tracking, protocols, etc…

On the other hand, if we were re-building a system because it’s unmaintainable and technologically obsolete, surely some principles about modularity, testability, new technology stack, etc… will appear.

Finally, lightweight Architecture will be needed when working on a new experimental product focused on a new market niche due to the uncertainty of the product itself.

Many enterprises have their own framework which implements some of the Architecture’s principles. Using it properly can be tremendously worthwhile when the agile team is building a solution. To do so, we should ensure that, at least one of the team members, will deeply understand such a framework ensuring efficiency, identifying flaws and helping to enhance it.
Software Architecture and Agile Methods in large enterprises
One may ask, how can autonomous and self-organized teams make the best of, as well as taking advantage of the Software Architecture? How can we let Software Architecture evolve without holding up the teams?

Autonomous and self-organized teams use to be focused on a specific area within the whole enterprise, which is great. Nevertheless, it’s quite difficult that such a team will have a global insight that let them anticipate problems that might appear outside its context.

Likely, they won’t understand the whole system and this fact may lead them to build redundant solutions or heterogeneous designs within the enterprise’s global context: maybe other teams had dealt with the same problem before. That’s what makes it desirable to have one person or a group accountable to look after the Software Architecture at a high level.

On the other hand, improve and optimize the reference Software Architecture, and the innovation process itself shouldn’t be a centralized task owned by a group of people but something that could emerge from any team within the whole organization. Obviously, every new idea (capacity, innovation, component, etc…) that will emerge have to be managed and included in the reference Architecture in a centralized way.

There is an interesting concept within the SAFe Framework that tries to take advantage of both approaches called Agile Architecture. The starting point is a bit of Software Architecture (upfront design) which is retro-feeding with the emergent design of the autonomous teams.

Doing so we reach two benefits:
- Having a reference Architecture which helps us to build our solutions
- Let the teams have a degree of innovation that, at the same time, will feed the Architecture and will allow other teams to take advantage of that.
How can we keep Software Architecture and Agile Teams to be aligned?

When we mean agile and autonomous teams we also refer to multi-skilled teams. Such teams are composed by dev-ops, scrum master, product owner, frontend developer, backend developer, QA, technical leader and so on. Here is where the technical leader plays a critical role.

The Technical Leader or Software Architect will be accountable to share the Architecture’s Vision and Roadmap within the team. He or she will be in charge of solving technical issues, handling the innovation requirements and synchronise them with the Reference Architecture.

Of course, the Software Architect isn’t an authority but a mentor who teaches and helps to improve the effectiveness of the Agile Team working quite closely with them. Moreover, he or she must have a deep understanding of the Reference Architecture and has to keep in contact with the rest of Software Architects whose work with the other teams (Software Architecture Chapter?).

If we want to have autonomous teams that won’t result in chaos, communication and alignment of principles will play a key role. Coherence and consistency can only be achieved by introducing a degree of control.
Conclusion
Agile methods and Software Architecture aren’t incompatible but supplementary. Such Architecture shouldn’t be considered as a limiting factor over the team’s capabilities but as an enhancer within the Agile Supply Chain.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月21日：开源日报第343期

21 2 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《设计大师 Awesome-Design-Tools》
今日推荐英文原文：《What Will a Robotic World Look Like?》

今日推荐开源项目：《设计大师 Awesome-Design-Tools》传送门：GitHub链接
推荐理由：在各种各样有关于设计的方面用得上的工具合集，包括设计用户流程图这些直接用于设计的工具和图标，字体，颜色和动画等等设计材料方面的工具等等。不管是在设计个人网站还是在开发应用上，相信这些工具都能或多或少的派上用场。
今日推荐英文原文：《What Will a Robotic World Look Like?》作者：A. S. Deller
原文链接：https://medium.com/predict/what-will-a-robotic-world-look-like-6fc838c54341
推荐理由：机器人与人类共存的世界会是什么样子的
What Will a Robotic World Look Like?
A fully-automated Earth in which robots work with humanity in every conceivable way has been imagined a million times over in science fiction books, film, games and television. According to our dreams, we might end up living in a world reminiscent of “WALL·E”, in which machines assisted humanity in our environment-shattering quest for more-more-more that ruined the planet; a post-apocalyptic result of AI seeing Homo sapiens as a blight to be wiped out portrayed in “The Terminator”; or an Earth and Solar System where robokind and humans exist together in a strange dichotomy of harmony and distrust as envisioned by the works of Isaac Asimov.

If we were to place all of our imagined versions of a robo-enhanced future on a scatter plot, where the X axis is the timeline starting in the present (at 0) and going into the future (say, up to 1,000 years from now), and the Y axis represents the degree to which we get along with our robot companions as a percentage — with 0 being “Robopocalypse”-level mutually-assured destruction and 100 representing some kind of perfect utopia in which humankind and machines exist together in perfect harmony or have otherwise blended together into a new species — it might look a little like this:

The majority of what many people expect in the nearer future tends to the darker side of things. We compare robotics and the research into artificial intelligence that usually accompanies that with other similarly large advances in technology that often had some scary results. Indeed, work on atomic power began with bombs, led by military programs, and that is where much of the headway is being made today with robotics.

Everyone working in robotics and AI today generally agrees that our creations need to be designed from the ground up with distinct rules in place for how they will regard human life. A robot’s AI must be able to unmistakably recognize humans and, at all costs, avoid harming them…

But then we are back to the militaries of the world being some of the primary organizations spearheading robotics work. As I write this, the United States, Russia, China and other countries are all actively running programs to create drones and AI-controlled battlefield robots expressly designed to kill people.

Robots similar to the one in the video below will, one day soon, be self-directed by onboard AI.

This contradiction is where the problem lies, because already, before we have really entered our upcoming transhuman, robotic era, we are seemingly ignoring the advice of two generations of scientists and futurists who have collectively thought about such problems to the tune of millions of hours. Geniuses, visionaries and tech pioneers like Kurzweil, Musk, Hawking, Page & Brin, Asimov, Vinge and many others have warned of the inherent dangers of AI and robotics for decades.

We, as in most of the world’s citizens, do not want an Earth dominated by killer robots. This is the kind of world we want:

Credit: http://actuatorlaboratories.blogspot.com

We want a world where robots and AI work alongside us to make everything better. But if most of the earliest autonomous robots are built with military objectives in mind, we will be setting ourselves up for a dark future.

Isaac Asimov laid out his trademark Three laws of Robotics in “Runaround”, a 1942 short story. He later added a “zero” law that he realized needed to come before the others. They are:

Law 0: A robot may not harm humanity, or, by inaction, allow humanity to come to harm

First law: A robot may not injure a human being, or, through inaction, allow a human being to come to harm.

Second Law: A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.

Third Law: A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

Asimov would apply these laws to nearly all the robots he featured in his following fictional works, and they are considered by most roboticists and computer scientists today to still be extremely valid.

Ever since the idea of real robots, existing alongside humans in society, became a true possibility rather than just the product of science fiction, the idea of roboethics has become a true sub-field in technology, incorporating all of our knowledge of AI and machine learning with law, sociology and philosophy. As the tech and possibilities progressed, many people have added their ideas to the discourse.

As president of EPIC (the Electronic Privacy Information Center), Marc Rotenberg believes that two more laws should be included in Asimov’s list:

Fourth Law: Robots must always reveal their identity and nature as a robot to humans when asked.

Fifth Law: Robots must always reveal their decision-making process to humans when asked.

Credit: Boston Dynamics

It’s evident that the main thrust of most of these tenets is we must do our level best to keep our robot creations from killing us. If we consider them to be the “children” of humanity, we certainly have our work cut out for us. As a whole, most parents do a good job at raising kids who end up respecting human life. But a not inconsiderable percentage of the population turns out to be rather bad eggs. Sometimes the cause is bad parents, sometimes it’s bad genes, and other times there is no evident cause.

If we find ourselves living in the Singularity, and our children rapidly exceed any of our abilities to keep tabs on them, we may not be able to rely on any rules we set for them. Their evolution will be out of our control. We could quickly find ourselves in a position similar to where we have placed the lowland gorilla or giant panda.

Because of this, it may be best to instill in them the morals we hope we ourselves would better follow, and hope that our children can police themselves.

Thank you for reading and sharing.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月20日：开源日报第342期

20 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《心理健康 awesome-mental-health》
今日推荐英文原文：《Notes on Learning To Code》

今日推荐开源项目：《心理健康 awesome-mental-health》传送门：GitHub链接
推荐理由：不管是什么时候，心理健康都是很重要的。这个项目就是关于软件行业中心理健康的各种资源——包括推荐的书籍和演讲，兴许其中的一些正好能够解决大家可能在工作中遇上的问题。不管工作有多么累人，要记住自己的健康才是第一位的，如果因为工作而导致不管是心理还是身体上的不健康都是本末倒置。
今日推荐英文原文：《Notes on Learning To Code》作者：Bryan Jordan
原文链接：https://medium.com/streamplate/notes-on-learning-to-code-6893340ea470
推荐理由：推荐给自学编程者的一些提示
Notes on Learning To Code
Having taught myself how to code to build Streamplate a friend asked me,

So this is my response that I’ve generalised because I think others will be interested.
As with any concept, its structure can appear imposing because of its unfamiliarity. Consider the following:

With no understanding of electrical engineering let alone circuit schematics this is naturally confusing for anyone. Recognising that the confusion is a function of unfamiliarity is important in learning anything — because it points your attention towards the concepts that are out of your understanding.

Similarly, coding has the problem of being visually off-putting — because you don’t understand it — not because it’s inherently difficult to understand. They’re two separate problems and it’s important to repeatedly remind yourself that you always have the ability to change this state and learn how to code.

In short, coding is easy.
```
print "Hello"
```
Above is a simple Python script, program, code, whatever you want to call it. That’s it.

What makes coding easy is this:
1. Write code,
2. Run the code,
3. See the mistakes,
4. Fix the mistakes,
5. Run the code again,
6. Repeat until completion. Not many other industries have an ability to simulate their task’s execution before delivery. That isn’t to say that there aren’t areas of coding that aren’t hard — the readership here is supposed to be those learning to code. There’s plenty of ways code can become hard through optimisation techniques, pursuing languages that are designed to optimally work with hardware and less so with programmers, managing networks of competing code — eg. web-servers and their networks and so on.
  
  The point is that with coding you have the ability to fix any problems with relatively no cost — and so again, the burden is on your own willpower to do so.
  
  Keep your perspective in check when you’re faced with problems during development — you’re writing a simple program, not the code for the in-flight software for the Apollo and Skylab missions (Margaret Hamilton — the woman next to the stack of pages — all code).
  
  It should be obvious now that the most important challenge with self-teaching relates to motivation. If this crumbles or your own willpower falters, then there’ll be no drive to overcome some of the issues you face — and to a newcomer, they can be overwhelmingly brutal.
  
  As for coding itself — as a general recommendation without knowing your personal circumstances, I’d suggest Python.
  
  Coding is an interface — just like how writing on paper is our way of communicating to other people — this is how programmers speak to machines. And just like writing, there can be more efficient ways of speaking, whether that’s with slang, verbosity or abbreviations and so on, there’s different ways of programming.
  
  The key metric for programming is speed — the faster it can execute, the more code can be processed and hence the computer has greater utility value.
Some languages can be processed faster by the machine because there’s less interpretation to be completed — yet they can be harder for a programmer to manage. Languages like this are, C, C++ and (somewhat) Go.

Languages that are easier for programmers to manage and aren’t generally as fast to execute (albeit this is a generalisation, there are ways to nearly-match speeds with C) are primarily Java, Python, JavaScript. JavaScript is mostly used for websites and some server-side operations while Python and Java are quite versatile and multi-purposeful.

To learn how to use Python you first need a way to write code through an app. My recommendation would be either Visual Studio Code or Atom, both free.

After you’ve installed either of these, you can begin coding.

To get you started, these are my recommendations for forums/search engines that are general enough to accommodate most queries:

YouTube — will provide video-based explanations and implementations of most of the problems/concepts you’ll encounter.
Stack Overflow — one of the few industries to have such an exact Q&A forum with such reliability and accessability. A Google search with your problem will most likely produce results linking to Stack Overflow. In fact if you want to know where your first step is into programming — here it is.
sentdex — a well-skilled programmer that works and documents really cool projects (using machine-learning for the cars in Grand Theft Auto 5 to become self-driving, financial modelling and web-crawling etc).
Google — naturally this will produce a range of options to consider, but most of these will link to either YouTube or Stack Overflow.
Depending on your level of motivation I think there’s a better way to learn how to code, yet it’s much harder. It forces you to understand concepts and also produce ideas rather than simply following guidelines and in a sense, colouring in between the lines.

I’m an advocate for practical, parallelised learning. Rather than a serial implementation as many teaching systems follow, for practical-based tasks such as programming, the final result rests on the delivered product, not the ideas behind it. The idea with this type of learning is that the implementation isn’t necessarily perfect each time, but you’re learning more faster and at each epoch in your education, your general understanding has grown rather than a siloed section of a concept.

As such, I think it’s better to begin independently coding as quickly as possible because it’s not hard, coding’s difficulty is grounded in its unfamiliarity. Overcoming this as quickly as possible produces much better results. Secondly, there’s nothing to suggest that learning the theory or modularising the concepts has to be mutually exclusive. Thirdly, programming lends itself nicely to ‘trial by fire’. If your code doesn’t work — check the errors and fix your code accordingly.

So with this said, I think the best way to learn how to code is with a project in mind and exclusively pursuing this. If you don’t have one — then following this initially is a good start.

If you do have one, then you know the resources to use for any questions you have.
Good luck!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/