开源日报 - Page 185 of 262

2019年1月7日：开源日报第305期

7 1 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《方便调试的 CSS Debucsser》
今日推荐英文原文：《How Producing Electronic Music Helped Me Learn To Write Code》

今日推荐开源项目：《方便调试的 CSS Debucsser》传送门：GitHub链接
推荐理由：这个项目允许你很轻松的查看网页上每一个元素的 id，class ，大小和边框范围，在你对着自己的网页进行调整的时候相当管用，最起码你不再需要打开 F12 的调试来一个个慢慢找了。它的 chrome 插件正在开发中，到了那时安装将会变得更加方便，如果需要经常写网页的话可以考虑加入自己的关注列表了。顺带一提，示例里的 id 一栏中那个不像是 id 的表情符号表示的不是某个 id 而是不存在的意思……不要再对着源码找这个 id 了。
今日推荐英文原文：《How Producing Electronic Music Helped Me Learn To Write Code》作者：Spike Burton
原文链接：https://medium.com/@spikeburton/how-producing-electronic-music-helped-me-learn-to-write-code-c9cbcf8fe887
推荐理由：电子音乐和写代码看上去是两个完全不相干的事情，但是实际上有着一些共同点
How Producing Electronic Music Helped Me Learn To Write Code

A project file in Ableton Live 10

Producing music, just like working with computers and writing code, is an interest and passion that I have maintained on and off for the majority of my life. Creating music and writing code are similar disciplines with a like set of rules: learning and understanding the language, establishing form and structure, and iterating on what you already know. With programming, you have to learn the syntax and idiosyncrasies for the language you are working in, as well as learn established best practices. With music production, you have to learn music theory, arrangement, sound design, and mixing/mastering. With programming, you have to learn the popular libraries and frameworks and how to build with them. With music, you have to learn the tempo range, structure and sound palette for a given genre. Finally, both disciplines rely heavily on the concept of iteration: gradually building upon a base skill set with more advanced topics until “mastery” can be reached. This last concept took me some time to understand, and it is essential to embrace in order to enjoy the process.

When I first started to learn to code as a young teenager, I wanted to create a massive sprite-based RPG. The undertaking was far beyond my ability at the time, and after months of frustration trying to figure out where to even start, I gave up. I was reading any book I could get my hands on: C++, Game Design, Graphics — you name it. Although some of the concepts were over my head at the time, I gained a solid foundation in computer science concepts and how designing a project should work. I later took AP Computer Science in high school, which helped me to solidify some of these ideas. However, my dream of creating something impressive was put on hold.

When the Bass Music scene started to emerge in the mid-2010’s I was again determined to figure out how to create something unique and innovative. I watched countless YouTube tutorials on sound design, arrangement, mixing, and mastering. I read any and every blog post I could find about electronic music production. However, I spent barely any time actually making music. I was convinced that I would retain this information and eventually sit down to write a masterpiece.

And then I finally sat down to write.

As expected, what I was able to create was nothing like what I heard in my head. I was so discouraged and embarrassed with my initial output that I wanted to give up completely. Why wasn’t I instantly great? I had watched practically every tutorial on the internet. Why couldn’t I instantly create at a professional level? I knew deep down that I had the ability to become a great producer. What I did not understand, however, was the process that it took to get there.

As I started to sit down and write more everyday, I started to make progress and overcome the frustration. I tried to divide up my writing sessions into smaller tasks: I would take a day just to experiment and design bass sounds. When I got to a point that I didn’t know how to recreate a specific sound, I would seek out a tutorial and create my own variation on it. I would spend a day just creating build sections, and focus on how to create and release tension. I would watch a tutorial on creating a build and then make my own from scratch. I began to figure out how to piece together all of these smaller tasks, and over the course of a year, finally completed my first track that I was proud of.

The most important takeaway from this experience is that the process of making music taught me how to learn. This sort of “meta-cognition” is — quite arguably — one of the most important skills that you can master. You don’t just sit down one day and create a masterpiece: it’s a long process of learning how to do a lot of little things properly, all of which build on top of each other. Learning how to write code is the exact same process, I have discovered. It is a process of patience, consistency, and actually writing code.

When I recently decided to start learning to code again, I realized that I could transfer my knowledge from producing into programming. My experience made me realize that the most important thing to do was to learn in a structured way and to continually apply what I had just learned. After learning some HTML/CSS and JavaScript, I created this simple web app. I am finding this process to be efficient and enjoyable — instead of becoming frustrated, I have learned to relax and enjoy the ride. I know that if I continue to learn and build, I will eventually reach mastery. Knowing that gives me comfort and the will to keep on keeping on — and I hope that it helps you, too.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月6日：开源日报第304期

6 1 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《落入起点 homemade-machine-learning》
今日推荐英文原文：《The Most Important Points Nobody Told You Before You Started Building That App》

今日推荐开源项目：《落入起点 homemade-machine-learning》传送门：GitHub链接
推荐理由：这个项目是对于一些 Python 中流行的机器学习算法的实现，包括它们的数学原理以及示例。由于这个项目是为了帮助学习者理解它们的，所以并没有使用其他库而是从头开始完成它们，如果要用于实际使用中的话并不是一个太好的选择，不过对于想要加深对这些算法的理解的人来说，这个项目可以说刚好适合他们。
今日推荐英文原文：《The Most Important Points Nobody Told You Before You Started Building That App》作者：Tomer Dicturel
原文链接：https://medium.com/swlh/the-most-important-points-nobody-told-you-before-you-started-building-that-app-f6ebbd6a32b5
推荐理由：一些只有实际做起来才会发现的经验——在开发软件方面
The Most Important Points Nobody Told You Before You Started Building That App
For nearly 50 years — ever since Frederick Brooks published the classic “The Mythical Man-Month” — software development teams have struggled with how to build a project on time and according to spec. It’s no easy task. Here’s what they are forgetting to tell you before you started building that new app…

The final product will look nothing like the original specifications

Building an app should be simple enough. You sit down a few people in a room, agree on a few specifications, and then let the smartest people in the room go to work coding what you just finished discussing. Easy enough, right? Wrong. There is a very high probability that the final product will look nothing like the original specifications. There are a number of very good reasons for this, and it has nothing to do with the “incompetence” of the software development team. Deadlines change. Plans change. In some cases, even the original problem you were trying to solve changes. In fact, it’s very much a miracle anything actually gets built in the end.

The more stakeholders you have on a project, the messier the final result

On the surface, this would seem to make perfect sense to limit the number of chefs in the kitchen, yet you’d be surprised at just how many perfectly sensible people ignore this. Instead, there’s a rush to involve not just the development team, but also the sales team, the marketing team, and maybe even the guy down the hall who has a funky, made-up title on his business card. And what happens next is like the old-fashioned game of telephone, where each person who hears a conversation repeats it slightly differently to the next person in the chain. According to what is now known as Brooks’ Law (in honor of Frederick Brooks), “adding manpower to a late software project makes it later.”

There will always be one part of the finished product that nobody knows exactly what it does
In a best-case scenario, there will always be a direct one-to-one mapping between all the features originally drawn up by the software development team, and the final features that appear in the app or software. But here’s the problem — most software development teams are under so much pressure to get the project out the door that they will skimp on the documentation of what each line of code is actually supposed to do. Repeat this enough times, and it inevitably leads to a “feature” that nobody really knows what it does, or how it even appeared in the first place. (And whatever you do, don’t call it a “bug” — it’s always a “feature”!)

One person on your team will be in charge of moving the goalposts

As much as people like to talk about “being in alignment” (or whatever the latest MBA 101 jargon happens to be), people are rarely in alignment. That’s what makes us people, not machines. And one of those people will (unofficially, of course) appoint himself or herself as the person in charge of moving the goalposts. You know, the person who shows up at the Monday morning meeting and announces out of nowhere that the project deadline date has been moved up a few weeks, or that a long-forgotten feature is now “mission-critical” and must be added immediately.

Conclusion
So the next time you sit down with your team and start to hammer out the deadlines and specifications for your next software project, keep these points in mind. It might just save you a lot of blood, sweat, and tears.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月5日：开源日报第303期

5 1 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《蓝猫淘气三千问 awesome-interview-questions》
今日推荐英文原文：《What I want (and don’t want) to see on your software engineering resume》

今日推荐开源项目：《蓝猫淘气三千问 awesome-interview-questions》传送门：GitHub链接
推荐理由：这个项目里究竟有没有三千问没人数过，不过里面都是面试时要用到的问题可是实打实的。各种语言，数据库，算法，网络等等方面都有涉及，如果想要为春招或者之后的秋招做准备的话，这个项目既可以作为对面试时题目的提前了解（虽然实际上看看想要去公司的面试题会更好），又可以作为对知识的检验，一举两得。
今日推荐英文原文：《What I want (and don’t want) to see on your software engineering resume》作者：James S. Fisher
原文链接：https://medium.com/job-advice-for-software-engineers/what-i-want-and-dont-want-to-see-on-your-software-engineering-resume-cbc07913f7f6?source=topic_page———2——————1
推荐理由：不仅是面试时的表现，自己的简历也同样重要，这篇文章就介绍了应该在简历上写些啥
What I want (and don’t want) to see on your software engineering resume
Asking what should be on a resume is one of the most common questions I hear. I’ve seen thousands of resumes, interviewed hundreds, and hired or helped hire dozens, so I’ll describe exactly what I’m looking for when I’m presented with your application.

Photo by Kelly Sikkema on Unsplash

Resume or CV?
In the US, documents describing your qualifications and work history are called résumés. In the EU and elsewhere known as a curriculum vitae, or CV. Either way, the purpose is the same: a relatively short document which summarizes your skills, work history, education, contact information, and anything else that can be used to estimate your “fit” for a given position.

I’m based in the US, so I’ll give a US-centric view of resumes, but I’ll attempt to point out differences with CVs in areas in which I’m familiar.

Why do I need one?
A resume is required as part of almost every job application. If you see a job listing online and click “Apply,” the next page will almost certainly ask you for your contact information and a resume file. Yes, getting a job is a highly-subjective process that involves interviewing and negotiation, but providing an employer with a resume is the standard first step before any of that can happen.

The resume serves to get your foot in the door. After a job listing is published (you can read how job listings are created here), a recruiter or hiring manager will be inundated with applications, and this person (or people) will compare your resume with all of the others, so it’s vital that you provide the same kind of document to put you on an even playing field with everyone else.

How long should it be?
Do your best to keep it to a single page. A second page is acceptable, but anything past a second page will probably be ignored.

Recruiters and hiring managers and other decision makers are usually looking at many resumes at once, so it’s important to put all of your best information up front, above the fold.

You can ignore this rule if you’re in academia, where all of your previous work and publications are expected to be listed out.

What format should it be in?
PDF, please. Dealing with anything else is a hassle, and Word docs and Google Docs links will just be converted to PDFs anyway. Plain text is hard to read when printed out. If the employer is using a decent applicant tracking system, it probably handles PDFs just fine.

Do I need a cover letter?
My suggestion is that, if the application process or job listing asks you for one, include it. If you aren’t prompted or asked for a cover letter, don’t bother. For software engineers, nobody really pays attention to them anyway.

You might be able to get some extra leverage up front by boasting about how excited you are about the company. But you can always make up for that by sounding excited after the interview.

If you need to write one, keep it short (2–3 paragraphs). Mention how you heard about the company and the opening, and mention how your specific skills and experience will be a good fit for them.

I’ve never made a resume. Where do I start?
Easy. First, google “software engineer resume” on Google Images. Next, check out the free resume templates on Google Docs. I think the “Serif” one looks best.

A guide to resume structure
I want to see the following things on a resume, in order:
- Contact information
- Skills
- Work Experience
- Projects (if notable or you don’t have much work experience)
- Education
- Any other awards or interesting things to help you stand out
I’ll expand on each of these below.

Contact information
Please give me, at the very least, your name, email address and phone number. If you use a nickname, express that somehow, maybe using quotes: James “Buckeye” Fisher.

An exact mailing address probably isn’t necessary since we live in the digital age, but it might be useful to list the city, state and country where you currently live so an employer might know ahead of time whether they will need to offer a relocation bonus.

Do include any profile URLs you think are relevant, such as your GitHub profile or LinkedIn. Including a GitHub link (or equivalent) at the top is great because I’ll immediately click on it and start looking at your code.

Do not include a picture of yourself. This is much more common with CVs outside the US. Adding a picture only lessens your chance of success due to potential bias from one or more of the resume reviewers or interviewers.

Skills
Listing technologies you’re familiar with is useful for a handful of reasons:
- It gives me an instant overview of the breadth of your computing background and a birds-eye view of whether you’ll be a fit for the role.
- You’ll pass any human or software filters that are looking for the keywords we want.
- It secretly tells me your level of attention to detail and familiarity with an area. Did you capitalize JavaScript correctly? Do you list which Linux distributions you use, or just say “Linux”?
Do include, in order of familiarity, your preferred programming languages, frameworks, operating systems, and any other software you care to mention or think might be an interesting icebreaker (like Adobe After Effects or Blender 3D).

Do customize this list of skills (and everything else on the resume, for that matter) to the job description. If the job is for a Ruby position, list Ruby first in the skills, regardless of how well you know it. You want to make the person reviewing your resume think, “Oh, good! This is what we’re looking for.”

Do not include anything you don’t want to be asked about in an interview. Anything you put on a resume is fair game. If you put MIPS assembly on there because you took a course in college years ago, I’m going to ask you about it.

Do not list certifications unless they are industry-wide accepted certifications that are pertinent to the job. The only two I can think of that fit this criteria are from Microsoft and Cisco. There are many online certifications out there for newer technologies like JavaScript, but the reality is that they are meaningless and a waste of money. Our industry does not require licenses, and your skill in an area will be determined during the interview process.

Do not list “skill ratings” from sites that provide them. There are sites out there that will certify you as “five stars” in things like React or jQuery. These rankings are meaningless for the same reason as bogus certifications above. (This does not include your rank on StackOverflow or TopCoder or HackerRank, since those are noteworthy talking points despite being not that meaningful.)

Do not list Microsoft Word. Everybody knows how to use Microsoft Word.

Work Experience
This is the meaty part of the resume, hopefully. Work experience is important because it describes things you’ve been paid to do. If you don’t have a lot of work experience then you’ll have to fill space with projects (see below).

Each work experience should list the employer name, when you worked there, and 2–5 solid bullet points of what you accomplished.

Wording is important here. Use words that convey action and describe specific work, like developed, built out, created, delivered, oversaw, managed, shipped, designed, architected, led.

Do attempt to quantify the business impact of your work. If the software you built helped save time, whose time did it save, and how much? If you built and shipped a feature, how many users used it, and by how much did it increase revenue? These aren’t always easy to answer, but if you can, demonstrate that you understand that your work is about much more than checking in lines to source control.

Do brag about yourself. Yes, everything’s a team effort, but you helped build, test, and deploy that feature, so tell me how much of a good job you did. You stayed up until 3am to fix that broken server, so tell me about it. You found the root cause of a bug that nobody else could, and that’s important!

Do not lie. Lying can get your foot in the door, but in the software engineering industry, liars are quickly uncovered and dealt with.

Projects
If you don’t have a lot of work experience, you’ll need to fill some space with projects. Work experience needs to be impressive, but projects need to be interesting.

If you’re listing projects, I want to know not only what they are but why you built them. Good projects are ones where you were solving a problem you had. The best projects are where you solved a problem you and other people were having—sometimes these even turn into good business ideas. No matter the project, tell me about the hard parts you overcame and any other challenges you encountered.

Do provide links to the projects so I can click on them and poke around. Make sure that I actually know what it is, what it does, and what’s the most interesting thing to know about it.

Do provide links to the source code if possible.

Education
This section is usually short, but required unless you’re self-taught. If you have a college degree, list the years and your degree here. If you graduated from a bootcamp, mention which one and when you attended. If you received any awards while at school, list them too. Include notable clubs and other accomplishments.

Do list your GPA if it was good. If not, omit it. (Why would a two-star restaurant advertise themselves as having two stars?)

Everything else
This is the fun part. Put a line or two of things that people might find interesting about you, like notable extracurricular accomplishments or cool hobbies. You’re going to be in a room with people that don’t know you, and these little tidbits turn into good icebreakers that can get the conversation rolling.

Do not list languages you speak unless the job description calls for it. Listing your languages can be a source of bias that works against you.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月4日：开源日报第302期

4 1 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《扭一扭 wiv.js》
今日推荐英文原文：《How you can learn to code in 2019》

今日推荐开源项目：《扭一扭 wiv.js》传送门：GitHub链接
推荐理由：这个 JS 库可以为你经常用到的 div 元素加入一点小小的改变——让它变得非常的扭动。只要几行代码，就可以为它添加一个扭动的边框，盯着看久了甚至还可能会发现这玩意的内在具有魔性。如果网站上刚好需要这种画风别出心裁的边框的话可以一试。
今日推荐英文原文：《How you can learn to code in 2019》作者：Katerina Pascoulis
原文链接：https://medium.com/@KatAlexPas/how-you-can-learn-to-code-in-2019-5ef3688c330c
推荐理由：如何在新的 2019 年里学习写代码
How you can learn to code in 2019
A week ago, this interview with Ruth and I was published by freeCodeCamp. In the interview we talk about the coding bootcamp we took part in (Founders and Coders) and how our careers have progressed to since. Ruth is on her second full-stack software engineering role, now at the company I started.

Lot’s of people got in touch to ask how they could go about learning too. With the aim of sharing that answer more widely, here’s the advice I would give to anyone learning to code this year.

You don’t need any kind of technical background
I went through so much of the start of my time working in tech thinking coding was about already having a technical background. Or being good at maths. It isn’t. So much of it is learning how to learn, where to look and problem solving. You don’t need a computer science degree to build something.

In fact, having a non-technical background (I studied law) gave me way more transferrable skills for coding than I ever thought it would. I wrote a post on that topic alone

You don’t have to go all in straight away
There are so many resources that are free and online designed for beginners. There for you to access in your free time.

Take some time on the weekend or after work to start a course on Codecademy. They have a pro version (and will try to steer you into it) but they still have a lot of free courses on there. It also gives you an environment to code in within your browser (google chrome, safari etc). This means you won’t need to handle a more complex set up yet.

Another great option is FreeCodeCamp. Beginner and intermediate level content, all served up to you for free to try in your own time.

I have enough photos of this dog to use one for each section but I’ll spare you.

Find your cohort
The coding bootcamp set up works as it makes you part of a cohort of people, going through the same experience, at the same time as you.

Find your cohort. Founders & Coders and FreeCodeCamp both have communities online. Having other people to work through problems with really helps.

One of my favourite xkcd comics: https://xkcd.com/979/

You can re-create the in-person benefits of a bootcamp by going to meet-ups designed for beginners.

If you’re from an underrepresented group check out Codebar. It’s an evening meet up, often hosted by the kind of tech company you might want to get a job at. You’ll be paired with a mentor and work through a problem of your choosing together (don’t be intimidated by not knowing what to work on. The FreeCodeCamp exercises are great for this).

Founders and Coders also run a meet-up called ‘Coding for everyone’ with a similar vibe (not just for under-represented groups).

You could also put together your own group in your local area or online.

My co-founder and I did this while he was still at his job and I’d just started on Founders & Coders full-time. We’d meet up at someone’s office, order food and work through coding problems. Each week we’d try and get a few more people involved. We used Facebook to organise it and kept it to friends of friends/colleagues

You could also do this entirely online using community tools like Slack or Gitter.

Choose your outcome
Now you’ve gotten started, you need to figure out what you want to achieve.

There’s never really an endpoint in learning to code (check out Dan Abramov’s post on all the things he doesn’t know yet. Dan works for Facebook on a commonly used front-end framework called React).

With the tools above you can learn how to build a simple site and understand a bit more about how the web is put together.

If you want to become a developer full-time there are a few options. What works for you depends entirely on what your lifestyle can support (savings, dependants, location).

Some of our cohort at Founders & Coders

Teach yourself
I think this is the longest and hardest route in but also the cheapest. I didn’t do this so you should check out Linh’s blog (she’s now a software engineer at Asos). Linh spent the best part of a year learning in her free time alongside a full-time job. My co-founder learnt on the job in his role and putting in the hours after work. It is definitely possible.

Take an evening course
Recommendations here will be London centric as it’s where I’m based.

CodeFirstGirls run evening courses for free if you’re a woman and within a few years of graduating university. They run paid for professional courses too.

General Assembly run evening courses and they are pricey. I don’t know anyone personally who has taken a part-time course with them so talk to ex-students before committing.

Go full-time
In my opinion this is the quickest way to get to a level where someone will pay you to write code for them.

I wrote about my decision to do that in a post. The TLDR is I wanted to focus on coding full-time and evening work alone wasn’t enough.

Founders & Coders was the bootcamp I took part in. There’s no cost to you other than you having to support yourself in London for 3–4 months (which isn’t trivial).

Makers Academy is a paid bootcamp. I’ve got friends who have gone through it and gotten great jobs afterwards. Both of the above I can personally recommend.

Also checkout Lambda School (US) and General Assembly. I don’t have personal experience of these so again, talk to students who have gone through them and gone onto get jobs afterwards.

I haven’t contributed to our main codebase since April 2018 so this is probably the last thing I’ll write on this topic. As CEO at Personably I handle everything but the tech now.

I talk through my career path: from law to crowdfunding to coding to founder in this podcast for GeekGirl if you want to learn more.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/