octref

Operator[0]

[0]: http://www.typography.com/blog/introducing-operator

I really like Zach Holman's comment on this one.

---

[0]: https://github.com/holman/ama/issues/698#issuecomment-118547...

I can't remember who said it initially, but my favorite sentiment on all this is:

> The only people still using Ruby are the ones making money.

In other words, I think it's a pretty great, stable community of people who use it in production and have seen it all, so to speak. I kind of include Python in this, too- besides the obvious syntactical similarities, I think they are pretty similar in terms of ideology.

I'm in a bit of my third honeymoon with Ruby (and Rails) this summer. I've been seeing a lot of people in the Go community, for example, talk about "just use the http libraries, no one needs a framework" and I think they're fucking bonkers, or at the very least write backend apps with no UI and no more than two contributors on the project. Frameworks like Rails give you so many security, development, and deployment niceties that I have zero interest in rolling my own anymore. (I saw a "screw frameworks" Go talk that spent ten minutes on how to reload code in development, for example... that was a solved problem for me in 2005.)

I'm kind of in love with the idea of writing everything in Ruby (or something similar) and when it makes sense and can be provably improved, extract it out in something like Go or C. The Go+Ruby combination in particular is super attractive to me, and it's likely going to be fine for the foreseeable future, I think.

---

[1]: https://github.com/holman/ama/issues/698#issuecomment-118958...

> The recent post from Parse Engineering Team [...] if you look at GitHub also, the number of Ruby repos are getting lower over these months.

I think looking at these examples don't the whole picture here. GitHub, for example, is a fairly feature-complete product, and their next few years will likely focus on optimization work. If you have a mature product, you have a very clear performance profile of what's breaking, what's fast, and what's slow. That's why GitHub, a seven year old company, is more likely to open source Go libraries at this stage of its life rather than Ruby libraries (for example)- it's obvious which use cases can be targeted for speed, maintainability, and shareability.

Parse is another clear example of this- they have a codebase that they've worked with for quite some time, with obvious spots of improvement, so they switched to Go. If you're looking at new companies that need a fair bit of creativity, product development, and development speed, I think Ruby makes a lot of sense. Premature optimization is not just a waste of time, it's an exponential waste of time, as you might head in a wrong product direction that can potentially sink the entire company.

> I am wondering what's will be the next language gonna rule like PHP. Though there are JS tech is in the peak, I still not convinced to use it on server side. Go and Rust looks promising.

I'm really the wrong person to ask here, but I can't really imagine anything taking over like PHP did for the next five years or so. That was a pretty meteoric explosion, and there weren't a lot of clear and open source options fifteen years ago. I don't see JavaScript development being a flash in the pan, I think Go is clearly going to continue to increase in popularity, and I think languages like Ruby and Python and PHP will probably hit a decent cruising speed for the time being. Even .Net technologies have a brighter future ahead of them again. There's a lot of choice right now, there's a lot of resources flooding into open source from companies who clearly want to compete in the community, and there's a ton of stealing of good ideas between communities rather than getting siloed off in the past.

A decade from now, yeah, things may be completely different, but for the time being there's a lot of exciting choices and options happening. Kind of love it.

More and more I feel the best data visualization for most scenario is just bar, line, and pie charts. They need no explanation and communicate information effectively.

Too many visualizations that are fun and fancy but convey ideas poorly.

I hope Medium have stayed invite-only. It's really hard to keep the content high quality when a lot of people flood in. The atmosphere changes, and that changes the culture and everything.

And I'm really sad that Signal v. Noise has moved to Medium, too. I miss the "Happy Monday" every time I come to the site. It feels like walking in a local bakery and having a friendly chat with the waitress. It's a warmth and sincerity I seldom find in today's websites.

I have a mixed feeling as a NeoVim user and long-time Vim user.

On the one hand, great to see such a huge release for Vim that brings so many features people have been begging for. Especially Async IO and JSON.

On the other hand, I hope Vim just become more stable and performant while not introducing new features. At the same time, I hope more development could go into NeoVim, and more people could start using it and writing plugins (not in Vimscript) for it. I want Vim to be my backup editor -- always there and reliable, and Neovim my working gear -- great features, joy to use, could have a few bugs that don't affect my workflow too much and are a natural result of fast-paced development.

I know this sounds really unfair to Vim devs. I'm sorry! I really appreciate the works you've done to make Vim amazing. But I feel for me, I just want to spend 95% of my time on one editor. Now I'm on the NeoVim boat, I feel like having completely switched my workflow to Atom from ST3, and just learned ST3 is going open source.

Ironically this page typesets Prof. Kernighan's email in a <pre> tag so mobile users could enjoy scrolling left and right 100 times to read it.

Why don't people just use lodash?

https://lodash.com/docs#padStart

It's well-tested, well-maintained, performant, with good documentation and has custom-build to leave out functions you don't need.

Isn't that exactly what he's not aiming for, namely "15 files and 900 lines of configuration that seem completely overkill"?

This seems to remove complexity but it just hides the complexity in the dependency. When something doesn't work out or he wants to change the behavior he still has to delve into these "15 files and 900 lines of configuration".

The worst thing I feel about hackathon is that it instills a bad culture of software development into young programmers. People spend a weekend writing crappy code and wiring APIs together, expecting to get money and fame. In the real world, we don't need more crude and fragile apps which leverage most of its work to frameworks. We need more solid, performant, well-designed apps. Sadly, none of these points are priorities at hackathons. We also need more programmers with empathy, perseverance, dedication, and ability to work on large projects without burning themselves out physically and mentally. Hackathon doesn't seem to cultivate these traits either. I hope instead of going to hackathons, more people can try building semester-long, meaningful projects and take time to maintain them, or try contributing to open source software.

I'm working on one and expect to be done around May. Just wondering, what kind of features do you want most?

I feel this one is more well-written and complete:

https://codewords.recurse.com/issues/two/git-from-the-inside...

> iTerm2 has been updated for the modern Mac OS X "flat" look and is stunningly beautiful.

It does look very polished! Just two things:

When you choose "No title bar", the rounded corners and drop shadows all disappear so it looks a bit too "sharp".

And it would be really great if you can add an option to specify internal padding, similar to urxvt's internalBorder.

Great work and thanks again!

What's needed for Webpack 2: better documentation.

Dropbox also ruined one of my favorite mail client on Mac: Mailbox. Somehow they did an update from 0.4x to 0.7x which made the client orders of magnitude uglier, crash more often, have dozens of rendering issues which never happened in 0.4x. They did this without communicating anything in their blog[0], and meanwhile totally ignores all the complaints in Dropbox forum[1].

[0]: https://blogs.dropbox.com/mailbox/

[1]: https://www.dropboxforum.com/hc/en-us/community/topics/20021...

I'm a junior college student doing some side projects[0] while taking 21 credits, jogging daily, going to mandatory club events, etc. Those except side projects take more than 40 hrs/week so I guess I have even less time for side projects than you.

I highly recommend you to read this talk script by Chris Wanstrath[1], one of GitHub's founders. Two of his suggestions:

- Turn off (or lower the frequency of) reading news/RSS/Twitter.

- Do a bit contribution to side project every day and get a streak. I feel John Resig's GitHub profile illustrates the point best[2].

I'm following these two suggestions on and off for a while, but I want to really do them for the whole year 2016.

And my suggestion is to go to some hackathons. You'll be amazed at how much you can get done during a weekend without distractions. Plus you meet a lot of awesome people, sharpen your skills and win prizes.

[0]: http://pwu.me/projects/

[1]: https://gist.github.com/defunkt/6443

[2]: https://github.com/jeresig

I think he's complaining about this page sometimes registers your slight scroll-down as scroll-up and goes up a screen.

In another comment[0] I also mentioned using Shadow DOM for modularizing CSS. However I got a comment "Shadow DOM is not the solution for CSS isolation for components." and the commenter referred me to css-modules.

I'm wondering what's the merit/advantages of using css-modules over using Shadow DOM to limit the scope of CSS rules.

[0]: https://news.ycombinator.com/item?id=10453076

Hey Wes. You mentioned there is a student discount. How much are the packages after the discount?

Maybe Typora[0]?

[0]: http://typora.io/

No I wouldn't mount each component into a Shadow DOM. For example if I have a React App with 2 major parts developed by 2 teams, I would just mount them onto 2 Shadow DOMs so each team don't need to worry about CSS classes collisions or whatever else that's on the webpage.

Really like this as a React dev. Recently there is a trend to use inline CSS to do CSS modularization in React, but I feel it's not really a clean approach. With Shadow DOM you can mount the whole React App onto a Shadow root and have perfect CSS encapsulation. Hopefully we can see Shadow DOM supported by major vendors' stable channel soon.

Thanks a lot for your input. I think I'll stay with ES6 and flow.

Did you also consider Flow[0] as an alternative? I'm now using ES6 with Babel to build some small side-projects and it has been a great experience. But as the codebase grows, I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS. I wonder what will happen to all those compile-to-JS languages once ES6 becomes supported everywhere.

[0]: http://flowtype.org/

Just to provide some information, as the linked page is in Chinese:

The company in question is NetEase. A lot of Chinese people use NetEase's products and have a NetEase account. Many also use the NetEase email to register for other internet services in China.

My rough translation to the wooyun Chinese page:

Submission time: 2015-10-19 16:40

Vulnerability type: Massive user data leak

Severity: High

Status: Informed CNCERT(National Computer Network Emergency Response Technical Team).

Short description: The leak contains over a hundred million transaction records, which include users' email addresses, email passwords, email password protection info, IP addresses, birth dates, etc. Password and password protection info are hashed with MD5. After decryption, most passwords can still be used to login the email.

I guess not, similar as you can compile non-GPL code using gcc.

I hope the author could use a more permissive license like MIT or BSD though.

Do you mean react-native, or is there a reactive-native I'm unaware of?

I doubt Github would frown upon this. Github Pages has already been handling a quarter million req/sec. [0]

[0]: https://github.com/blog/1992-eight-lessons-learned-hacking-o...

Nice work. Some suggestions:

1. Better to include a demo. If I'm using this service I'd want to know how the blog looks like.

2. The gif doesn't really look smooth. Maybe consider using a low-quality mp4.

This is something I'd personally use. A lot of alternatives exist on the market but none of them look as refined as Paper.

Paper looks really similar to http://onword.co (by Daniel Eden at Dropbox) regarding the minimalism and limitation on formatting. I guess Hackpad team is working on the backend.

I just hope this project will not end up like Mailbox. I've been using Mailbox on OS X for half a year. Although once in a while I encounter some bugs, it's still very usable. A few months ago, they released an upgrade from 0.4 to 0.7. The UI became uglier in orders of magnitude and many basic functionalities just broke. After experiencing it for 3 days I switched back to Mail.app. I have sent quite a few bug reports and suggestions, but got no response. I wonder if they still care about Mailbox at all.

Interesting how you consider it ego-bolstering. Can't you just ignore the leaderboard?

It seems a lot of effort goes into making this tutorial. The guy working on it seems to be running a business. Although it can be done without requiring a sign-up as you said, I also understand how the author would like more people to sign-up, follow the competition, and potentially use his company's service.

Writing good tutorial is actually pretty hard and time-consuming. Just making it open and not getting any benefit out of it is not a sustainble business.