Driven – A bicycle drivechain concept without derailleurs and chains - <AUTHOR> https://www.ceramicspeed.com/en/driven/ <comment><USER2> This company is really famous for selling really expensive "upgrades" that do very little for actual speed.

The resistance of the chain & pulleys is a very tiny percentage of the whole unless they're gunked up and not maintained/lubricated or are broken.

Pretty much all mechanical resistance on a bike is dwarfed by aerodynamic resistance. When the aerodynamic resistance is broken down the contribution of the bike is dwarfed by the contribution from the rider and his/her body position on the bike. When you start getting into the resistance from gear the helmet & clothes are more significant than the bike.

None of this stops them from selling $10,000 bikes to amateurs who are slow though.

It is free but hard work to go on a core strength + flexibility program that lets you access more aerodynamic riding posture. Working with a good fitter/coach will cost a little but help get there with less guesswork. Everything about getting fast on a bike is harder work than buying stuff.

<comment><USER3> I think the fastest bikes in a straight line are recumbent bikes because of the small frontal area. Nobody talks about it much (probably because nerdy middle age men are the only demographic with enough devil-may-care attitude to ride one in public)

<comment><USER4> Also they're banned in most racing events and horrendously expensive.

<comment><USER3> that's fascinating - I think common bicycles would probably have lots more variants if these hidden administrative rules didn't exist.

I'm reminded of the look of sport motorcycles. The design has been heavily influenced by an almost unknown source - a racing rule from many years ago that said the fairing should not extend forward of the front axle.

</comment></comment></comment></comment><comment><USER5> First, from an engineering perspective, this product is really cool and maybe for some well-funded Tour de France team it could make sense to test this out. But the price point, the lack of compatibility with components of existing drivetrains and the lack of compelling reasons to make the change, are going to be headwinds to adoption.

On page 3 of their brochure ([https://www.ceramicspeed.com/media/2979/driven_brochure.pdf](https://www.ceramicspeed.com/media/2979/driven_brochure.pdf)), they're showing 0.5% - 1.0% efficiency gains over a traditional drivetrain that is _cross-chained_ , meaning that if you use a traditional drivetrain correctly (i.e., shifting so as not to cross-chain) the gains are likely significantly smaller.

As ben7799 said, this company is primarily in the business of selling very expensive products that have minimal impact on performance.

</comment><comment><USER6> I'm sure this is a neat system, but it's worth noting that bicycles are already very efficient, the difference between their claimed efficiency and a properly set up traditional drivetrain is maybe one or two percent.

And any weight savings are probably useless due to the minimum weight required for racing. Pro bikes are basically at the point where they're having to add weight just to pass inspection. This system might have a bit less rotational mass in the "cassette" than a traditional cassette which would help.

<comment><USER7> I've ridded a half-decent street bike a summer or two. This thing was light enough that as a tall slightly chubby man I felt uneasy just getting on it, I kept thinking "this thing will crumble from my weight". I knew it was stronger than that, but my brain kept telling me something wasn't right.

And it was a pretty mid-range bike.

<comment><USER8> As a tall, lean cyclist I'm always a bit surprised by both the extremes that people go to in weight reduction and by the palpable speed difference that you feel when riding a light bike.

When I ride a 1980s steel road bike, we (bike+rider) weigh about 75 kg. On a modern carbon-fiber bike, we weigh about 71 kg. That's a 5% difference, but the latter feels like it has rocket boosters when I get out of the saddle to sprint up a climb, while the former feels like I'm carrying an anchor the whole ride. Borrowing a friend's hill climb fixie machine well under the UCI weight limit gives even more of an exhilaration of speed. But conversely, adding 30lbs of bags to go touring doesn't feel that much more difficult once you're up to speed.

<comment><USER9> I wouldn't be surprised if most of that difference in feel could be explained by frame rigidity rather than weight. I love my steel frame but I know it's not super efficient.

<comment><USER6> IMO it's probably that wheels are a lot lighter now. Rotational mass is a killer.

<comment><USER10> I've got two different sets of wheels for the same gravel bike. Its standard 42 mm wheels for gravel and 28 mm slick wheels I assembled for road. Same brake rotors and same gears on the back. The set of road wheels is about 1.5 kg lighter (3 pounds). The bicycle seems to fly with them. Rotational mass is really important and also slick vs threaded.

</comment></comment></comment></comment></comment></comment><comment><USER11> chains are a pain. But belt drives have been around for 10 years now and you hardly see them.

Chains are the most complex part of the bike with the most moving parts. You have to lubricate them, they stretch.. But they work well in all variety of conditions (even rusty and squeaky) and are fairly cheap.

Sheldon Brown's (RIP) bike pages have some good articles on the good old chain.

old school html ahead: [https://www.sheldonbrown.com/chains.html](https://www.sheldonbrown.com/chains.html)

[https://www.sheldonbrown.com/chain- wear.html](https://www.sheldonbrown.com/chain-wear.html)

<comment><USER12> Belt drives are comparatively expensive and don't work with derailleur gears. Internal gears, especially cheap systems, still cannot offer as many gears as a derailleur. Belts also need to be pretty tight and thus cannot be used on most bicycles with a rear suspension as the distance between the pedals and the sprocket changes under load. So many people opt against belts.

<comment><USER13> I have seen quite a few belts on internally geared hubs - a quick search turns up quite a few[1] commuters shipping w/ belt + Nexus internal hub.

1: [https://www.bikeexchange.com/blog/best-urban-belt-drive- bike...](https://www.bikeexchange.com/blog/best-urban-belt-drive-bikes-2018)

<comment><USER12> Absolutely: internal gear hubs are the only gears you can use with belts. They just tend to be substantially more expensive for the same amount of gears as a comparative derailleur. Internal gears also tend to have a higher friction than derailleur gears - the really good ones such as a Rohloff speedhub cost > 1000 EUR. Even a comparatively mundane Alfine 11 gear costs ~ 400-500 EUR. A pinion gear isn't exactly cheap either.

In return you get a mostly maintenance free setup. It's great, but I probably wouldn't opt for it for a city commuter bike.

</comment></comment></comment></comment><comment><USER14> The system isn't ready for prime time, but apparently it's a great way for CS to advertise!

<comment><USER15> I'm not accusing... but I'm struggling to see how this isn't just an ad.

<comment><USER16> For what it's worth, I upvoted the 'story' because I never heard of such a thing and it looks really cool. While I'm a little sad to read that this kind of thing doesn't actually really help, it's not that unexpected. Still, it looks neat, and once the price comes down (I didn't see any prices but I'm guessing it's hundreds for a few metal parts), I might want to play around with such a bike to see for myself. It's a little like other gadgets/gimmicks. (Some gadgets have use, others don't really.)

</comment></comment></comment><comment><USER17> Video of it working:

[https://www.youtube.com/watch?v=UFAQ6CzNm7s](https://www.youtube.com/watch?v=UFAQ6CzNm7s)

<comment><USER18> The above video doesn't show it changing gears... I was wondering how it did it. It is (sort of) covered in the "fully explained" YouTube video: [https://www.youtube.com/watch?v=-9gQ1KRhesM](https://www.youtube.com/watch?v=-9gQ1KRhesM)

Explanation: very complicated with a battery powered wireless electronic shift mechanism embedded in the drive shaft. The "fully explained" video doesn't show it changing gears either, just explains how they would do it. My take- away is that it _doesn 't_ change gears as of the making of the video (July 9, 2018) but "they have a plan..."

<comment><USER19> Correct in the video you reference, they say "this is how we invision the shifting will occur"

</comment></comment></comment><comment><USER20> I couldn't figure out what it was from the page, but the linked PDF has more information (rolling pinion to what looks like a driveshaft)

[https://www.ceramicspeed.com/media/2979/driven_brochure.pdf](https://www.ceramicspeed.com/media/2979/driven_brochure.pdf)

</comment><comment><USER21> How do they keep the bearings from skipping over the rear gear/disk? That disk and driveshaft would have to be extremely stiff to avoid flexing, especially in lower gears where the contact point is further out, and it looks like just a couple millimeters of flex will give enough space to skip.

</comment><comment><USER22> As far as I'm aware chain was introduced to allow for light weight while keeping vibration resistance.

Can't this pulley system be trimmed down even further to one bar transmission?

<comment><USER23> Based on my experience with motorcycles, chains are better than shafts for transmitting torque. Shafts tend to twist over their length in high torque settings, whereas chains just "pull" with minimal stretching.

Specific to this product, how the hell would you keep the 20-30 "gear" bearings on the shaft clean and operating smoothly in anything but lab conditions?

<comment><USER24> You can seal the bearings, but that cuts efficiency. That's not the only problem, though. The interface between the bearing and the bearing sprocket will make it rather unusable in very dirty conditions.

Their setup seems like an answer to a question no one was asking.

<comment><USER6> The gains you could get from improving drivetrain efficiency are very marginal. Everyone else is working on improving aerodynamics. That's the actual limiting factor in cycling, and it always has been.

</comment></comment></comment></comment><comment><USER25> Would this system be legal in professional competition cycling?

<comment><USER26> No, this violates current UCI rules.

"The front wheel shall be steerable; the rear wheel shall be driven through a system comprising pedals and a chain"

However, the rules do change and have been recently (like the removal of the 3:1 restriction).

</comment></comment><comment><USER27> Honestly, the price-point of these things makes it prohibitive for most people...I wish I could try one for fun though :)</comment>


Why No Twitter Search from Google & Yahoo? - <AUTHOR> http://battellemedia.com/archives/004796.php <comment><USER2> Google seems to index tweets very quickly. Occasionally I'll tweet something, go search google a few minutes later and find my tweet in the results already.

<comment><USER3> Seconded. I have google alerts and it seems that twitter (and github) are indexed almost instantly.

</comment></comment><comment><USER4> "It's going to be fascinating to watch" is getting to be quite the tired conclusion in blog posts, if it isn't already. What I do find interesting is that this blog post asserts that we've witnessed this kind of competition happening twice before and yet this time it will be fascinating.</comment>


Ask HN: What is your favorite productivity macOS app? - <AUTHOR> <comment><USER2> Pomotroid, "A simple, configurable and visually pleasing Pomodoro timer": [https://splode.github.io/pomotroid/](https://splode.github.io/pomotroid/)

Bonus that it's free and cross-platform.</comment>


HumanPredictions – Bootstrapping a SaaS app to $18k/mo in under a year - <AUTHOR> https://www.indiehackers.com/businesses/humanpredictions?utm_source=hacker-news&utm_campaign=interview-promotion&utm_medium=social <comment><USER2> He basically gets a spot in the family business which he uses as a launchpad to creating a SaaS product. Come on, this title is so far off from reality. No problem with what he did and it sounds like he does a great job, but let's at least keep the titles from indiehackers somewhat accurate. It gives a lot of people thinking about starting their own company really unrealistic expectations.

<comment><USER3> As someone who has known Elliot from the Chicago scene for the last ~10 years, I have to push back on this.

Elliot hustled his ass off doing his own thing, working recruiting for Groupon, working as one of the founding employees of DevBootcamp Chicago to get graduates gigs (and doing so with great success), and then back to his own recruiting before launching Human Predictions based on feedback from his clients and experiences.

He became, at least in my circles, the most trusted recruiter amongst developers. Many thought of him as more of an "agent" than a recruiter. Someone you could grab coffee with every six months who'd keep you in mind if the perfect gig came up. I referred friends to him all the time without concern that he'd spam them, hard-sell them, put them in whatever spot that was open just to reap the commission. He's always had the developer's interest in mind first and foremost.

I understand the sentiment that these stories can sometimes over-simplify the journey. Yes, he had the privilege of learning the family business at a young age. But it's not as if "having a dad that does X" makes it a trivial effort to launch a SaaS that does X. In Elliot's case, there was at least ten years of self-motivated hustle in-between.

<comment><USER2> Absolutely agree with you and my apologies if my comment made it out to sound like I felt like he did not work for what he has accomplished.

 _> No problem with what he did and it sounds like he does a great job_

My comment was about the indiehackers title and link. It seems to be a pretty common occurrence for that site to greatly exaggerate the 0 to $X and this article is unfortunately no exception. Much respect to Elliot for all he has accomplished.

<comment><AUTHOR> IH founder here. Why do you think the title is exaggerated? He did start his business less than one year ago.

Of course, any business depends on the skillset and knowledge that its founders started to build previous to its founding, but how do you put a start date on that? To build a company, you need business skills, a network, money, programming knowledge... for that you probably need professional experience... for that you need the ability to read and write... etc. Where do you draw the line? Everything always depends on what came before it. People get this. They aren't naive enough to believe that founders are born on day 1 of their companies with no previous life experience or knowledge of the world.

I agree it's dishonest to refer to a 5-year-old business as "an overnight success" as often happens, but how exactly is it misleading to call a 1-year old-business a 1-year-old business?

</comment></comment></comment></comment><comment><USER4> Wow! Maybe just me, hearing about a company bootstrapping to success instead of raising large rounds of financing is all the more inspiring.

<comment><USER5> 80% of the inc 500, the fastest growing private companies, haven't raised outside capital.

<comment><USER6> Do you have a source for that?

<comment><USER5> Some inc article I saw on HN with Sam Altman talking about how important startups are to the economy, couldn't find exact one.

<comment><USER7> Here is a link to the HN discussion to the article I assume you are thinking about. The wording was a bit different, which may have been why you didn't find it.

[https://news.ycombinator.com/item?id=12625642](https://news.ycombinator.com/item?id=12625642)

<comment><USER5> That's the one. The exact quote:

> Only twenty per cent of the Inc. 500, the five hundred fastest-growing > private companies, raised outside funding.

</comment></comment></comment></comment></comment></comment><comment><USER8> The underlying assumption seems to be that everyone uses LinkedIn/Facebook/Twitter. While it would be largely true, not _everyone_ uses those. What would your tool say about them?

<comment><USER9> Unfortunately because we are just looking at public data online (including Github, StackOverflow, and Meetup) if people don't use those services (or contribute to open source) we won't discover them or be able to a make a prediction about their likeliness to leave.

<comment><USER8> Maybe you should start looking at Keybase [0] too. It might help you link personal websites, github, twitter, ...

[0] [https://keybase.io/](https://keybase.io/)

<comment><USER9> Thanks! We do actually use Keybase for discovering social accounts as well.

</comment></comment></comment></comment><comment><USER10> I noticed the UTM tags you had on this link.

How is Hacker News performing as part of your interview promotion?

<comment><AUTHOR> Just started using UTM query params a few days ago, so I'll have more data when I write my monthly review for November! But in October, direct links from HN accounted for around half of my total traffic. More details here: [https://goo.gl/FMxdpc](https://goo.gl/FMxdpc).

</comment></comment><comment><USER9> Hey everyone, I'm the CTO and Co-Founder of HumanPredictions happy to answer any questions anyone has about the article or the company in general!

<comment><USER11> I'm curious if you've received feedback from software developers on what the experience is like being recruiting with your tool.

The agency spam approach you mention is irritating, but I would imagine that if you're correctly predicting when someone is looking to jump that would be less of a problem.

<comment><USER9> We actually do have a significantly better response from developers both because they're being reached out to at the right time, but also because a lot of our users are CTO's and Engineering managers who by the fact that they are technical can have a much better conversation with prospects.

<comment><USER11> Cool, that makes sense. I think a big part of the spam problem is mass template emails, so if your customers are emailing people directly it would be much better.

<comment><USER9> Completely agree, one of our core goals from the beginning of HumanPredictions has been to kill mass template emails.

</comment></comment></comment></comment></comment><comment><USER12> Would it be possible for a dev to see their own prediction (to prove ownership maybe leverage oauth of one of the sites: github, linkedin, etc)?

<comment><USER9> We don't currently support that through the application, but it is on our roadmap and something we very much want to build.

For now though if you reach out to me at email@example.com I'd be happy to let you know what our current prediction for you is.

</comment></comment><comment><USER13> Great story and many great lessons. Being "intentional about the people you work with" is a great piece of advice and one that we usually like to stress too when talking to aspiring entrepreneurs. We wrote about some of this too in a previous HN thread [https://betterthansure.com/answer-hn-growing-a-side- project-...](https://betterthansure.com/answer-hn-growing-a-side- project-30f17f6a10da#.ntvqg0q7z).

</comment><comment><USER14> This is really cool idea, I like how it uses data to predict behavior.

I have few recruiters that always hit me around the time when I get a little more free. They don't have this tool, just their spidey sense, but I bet they would like something like this.

<comment><USER8> I heard of such tools a couple of years back. So I'm sure those exist.

How well do those work if an entirely different issue.

<comment><USER14> Well, if people use twitter, github etc, they will be findable and their trace can be used to predict if they are 'jumping ship'. It is common to start blogging around the time you are looking to change work for example.

</comment></comment></comment><comment><USER15> Sounds like very similar to my start up NetIn[1] We also look at public profile updates and other signals to tell if a candidate is on the move. We also got to HN frontpage last night for our candidate job portal[2]. If there are people who would like to talk about what we've accomplished so far feel free to reach me at email@example.com

[1] [https://netin.co](https://netin.co) [2] [https://netin.co/candidates](https://netin.co/candidates)

</comment><comment><USER16> It's great to hear about your success!

For discussion's purposes, it's worth pointing out that there is a venture- funded company that is doing the same thing (but with a big data science team): [https://www.crunchbase.com/organization/entelo](https://www.crunchbase.com/organization/entelo)

</comment><comment><USER17> Now just let me come up with a product I can sell to developers that camouflages them to this product by simulating activity on these sites...

I wonder what their next line of business is at this company...selling this data to current employers to see when their employee is about to jump ship?

</comment><comment><USER18> This type of data mining of personal information feels kind of icky to me.

</comment><comment><USER19> I wrote a similar tool for recruiters (only analyzes LinkedIn profiles that you are viewing). Mine is significantly cheaper at $9 per month: [https://recap.work](https://recap.work)

<comment><USER8> Your site redirects (301) from HTTPS to HTTP!</comment></comment>


How to Build Decent Productivity Software - <AUTHOR> http://www.aaronsw.com/weblog/decenttodo <comment><USER2> If you actually are interested in building productivity software maybe you'd be interested in this user's anecdote.

I use a wiki to stay organized at work. Basically I use Textile as a substitute for neato Ajax todo lists:

h4. Stuff I gotta do today

# Item 1 # Item 2 ...

I don't think productivity software is for people who can't stay organized. A wiki or some other simple, flexible tool like that (Backpack from 37Signals seems good) has a lot of advantages over typing in Notepad: accessibility from mobile devices, version control, and all the goodness that comes with a simple data-driven web application.

I don't need the software trying to be a clever bugger telling me what to do and when, that's for me to decide. It's mainly just I don't forget little things and always have an extremely clear picture of what I've done and what I'll be doing in the near future for my boss and for myself. (Yes, my boss, I realize that's a quaint notion on this site.) Sticky notes, I've found, just don't scale.

I think simple wiki-like apps like Backpack are good enough that it would be hard to displace them as the best general solution for most people.

</comment><comment><USER3> I think the idea about the assistant telling you what you should be doing if you're not currently working on the top priority item is a great idea. We're going to add that to StreamFocus.com :)

</comment><comment><USER4> [shrug] I keep a list of things to do in version control. I think the real attraction of "productivity software" is that it's easy to make with a potentially large user base.</comment>


"Google is freaking because a lot of folks are vesting soon and these greedy, restless bastards..." - <AUTHOR> http://fakesteve.blogspot.com/2007/10/real-reason-google-hates-facebook.html <comment><USER2> How can it be avoided? The gold rush is quite unlike the golden age. The pace of creation is geometric, while the pace of improvement is linear. Creators and maintainers have different motivations. And so on.</comment>


Ask HN: What's happening with today's outage in a row? - <AUTHOR> Twitter went down multiple times, Let's Encrypt went down, and AppVeyor is suffering from network slowness. I can't believe they are just coincidence. Is there any large scale DDoS or other attack causing this? <comment><USER2> Why can't you believe it's a coincidence?

Apophenia.</comment>


Show HN: Record and share police/fire radio systems - <AUTHOR> https://openmhz.com/ <comment><AUTHOR> If you are interested in trying to listen your local radio system, try out Trunk Recorder: [https://github.com/robotastic/trunk- recorder](https://github.com/robotastic/trunk-recorder) It works with the cheap $20 RTL-SDR dongles.

<comment><USER2> Cool! I last played with it a couple of years ago. Will have to mess with it again. Great work!

Do you know if the newer versions of RPi or other small boards have enough power to run this (i.e. dedicated RX feed nodes sort of like the ADSB RX nodes)? I know DSD is pretty processor intensive.

<comment><AUTHOR> Thanks! So I have been playing with it on a RPi3. There are instructions here on how to build for the RPi: [https://blog.hypriot.com/post/building-a-64bit- docker-os-for...](https://blog.hypriot.com/post/building-a-64bit-docker-os- for-rpi3/)

It has about enough CPU to handle recording about 2 streams at the same time. I think part of the problem is that Raspbian does not have the GCC flags optimized for the processor in the RPi3 and doesn't have 64bit enabled. I played a little with this image: [https://blog.hypriot.com/post/building-a-64bit-docker-os- for...](https://blog.hypriot.com/post/building-a-64bit-docker-os-for-rpi3/) and it seemed to help a bit, but I didn't see huge gains.

People are using it with the ODroid, and I think they are able to do about 4 simultaneous recordings at the same time.

<comment><USER2> Are you using polyphase channelizer now, as opposed to individual XFIR tuners? If so, does that still provide better performance given sparsely occupied channels?

<comment><AUTHOR> Unfortunately, I wasn't able to find a nice generic way to make it easy to configure the PFBs. There is a good thread on it here, with some sample code: [https://github.com/robotastic/trunk- recorder/issues/76](https://github.com/robotastic/trunk-recorder/issues/76) If I can get a block of free time I am going to try and take another tilt at it.

I did switch to FFT based filters and that helped a lot. CPU requirements are a lot less. Using RTLs with 2M sample size, instead of SDR more bandwidth also helps. It is a poor mans version of HW-based channelization.

</comment></comment></comment></comment></comment><comment><USER3> Interesting. I thought that Germany was the last holdout of analog unencrypted cop radio - we switched to TETRA (digital and especially encrypted) some years ago.

Brings back some fun memories...

<comment><USER4> We have unencrypted police radio around here, but the most common thing you hear the cops say to each other is "Call me on my cell." Yay, transparency.

<comment><USER5> Certainly anti-transparency, but I'd say it's probably just easier for them. With a mobile (cell) phone call they can go hands free and talk in real-time in full duplex. That sounds better than waiting for the other party to finish and then pressing a button to talk to them... and using radio lingo.

</comment></comment></comment><comment><USER6> I've been dabbling in this area with a friend and this+trunk-recorder looks amazing.

The other solutions we ran across (Unitrunker, DSDPlus) are all built on rickety virtual audio cables running in Windows. They _work_, but just barely and are very brittle.

<comment><USER2> This works well; at least version 2 when I last tried it in the fall:

[https://github.com/DSheirer/sdrtrunk/blob/master/CHANGELOG](https://github.com/DSheirer/sdrtrunk/blob/master/CHANGELOG)

<comment><USER7> Something trunk-recorder does that sdrtrunk doesn't (appear) to do is work with multiple radios simultaneously. Each cheap SDR is only capable of receiving like 2MHz at a time, but if I combine like 6 of em I can cover most of the local trunked emergency radio system

<comment><USER8> Are you saying 6 is all you need for most locales? Or that is the case in your area?

<comment><USER7> sorry, should have been more clear. 6 was what I need for my area.

</comment></comment></comment></comment></comment><comment><USER9> Somewhat tangential, really glad people do this type of thing. I have an app (Scanner Radio) and I have it set to trigger an alert when a channel hits a predefined number of listeners, aka something bad going down.

</comment><comment><USER10> This is the amazing power of software defined radio. My favorite is to pick your 4 or 5 favorite FM radio stations and then have your 'radio' automatically play only ones that are _not_ playing commercials. :-)

<comment><USER8> How would you know when it is playing a commercial? Commercials are at predefined times? There is a DB of the times? Or the software just figures out its a commercial (higher volume?)

<comment><USER10> for 70's/80's rock its fairly melodic and the spectrogram for music is pretty distinct from commercials. But when I get some time I think I'll hook it up to some RNN code and 'train' it using a button.

<comment><USER11> During network programming, act on subaudible cue tones. Sometimes the affiliate relays will let a little bit of a tone leak before acting, and you can use the same cue. If someone's driving the bus by hand, you'll definitely hear them. This will serve you well during football games to remove local commercials, at least, though increasingly local breaks come with a 120+ network avail before the tones fire and the affiliate takes over, so your training would still be useful.

When you hear "after these words from your local station," watch for < 100 Hz tones. They're high amplitude and you won't be able to miss them; VU meters will often peg hard right during a tone, depending on the network. Should be a tone out and a tone in, and it is modulated so it'll be quite apparent.

Another helpful avenue to explore would be in-stream RDS metadata, if you're working with typical FM. It lags a bit, but if you buffer a minute back or so you can look for transitions when the RDS data changes. Then you can use the same trick a delay uses to backfill its own buffer, and pad silences to restore your buffer. You don't care about dead air in your application, so you can be more aggressive than broadcast equipment can. (Talk radio runs >30sec behind, usually, and the "dump" button on a delay flushes the entire buffer, synchronizing air and program. It'll then slightly extend silences to get air "behind" program again. It has a little screen on it indicating how far back it is, and it's cool to watch it zoom back when people stop talking. If you hear a station dump delay, you'll notice they won't take callers for a couple minutes; this is why.[0])

Teach your setup to listen for EAS tones and you're well on the way to a startup of some kind. I think this was attempted in the past, actually...

[0]: [https://en.wikipedia.org/wiki/Broadcast_delay#Computerized_d...](https://en.wikipedia.org/wiki/Broadcast_delay#Computerized_delay)

</comment></comment></comment></comment><comment><USER2> This is a really awesome application of SDR. It has really grown since being presented at the GNU Radio conference a few years ago.

</comment><comment><USER12> Does HAM radio still exist?

Would this capture it?

<comment><AUTHOR> It would depend on what type of modulation they are using. If it is narrow band FM, it should work fine. There are probably lighter weight solutions though. If you wanted to use a RTL dongle, you would also need an upconverter, since the dongles can't capture frequency that low: [http://www.nooelec.com/store/ham-it- up.html](http://www.nooelec.com/store/ham-it-up.html)</comment></comment>


Buck – A build system developed and used by Facebook - <AUTHOR> https://buckbuild.com/ <comment><USER2> I don't work in a shop where performance/speed is important, but I am looking for other ways to do things I would do in Make but...not in Make.

For example, my use-case is similar to what Mike Bostock described in "Why Use Make" [0] when explaining how he uses Make to build out his data tranformation process. Most of my work is data transformation/small-scale ETL, but I just haven't been able to get into Make beyond trivial work, and I often end up writing things in Rake (Ruby).

So I was wondering if other devs had tried using Buck/Bazel for everyday hobbies and projects, and whether you stuck with the new tool or went back to Make? The portability of Makefiles isn't a high priority for me, and I like experimenting with different systems for my own projects.

[0] [https://bost.ocks.org/mike/make/](https://bost.ocks.org/mike/make/)

<comment><USER3> These build systems become super handy once you're working on a large tree of many different software projects. For small projects not so much. It's probably easier to use the default build system of your programming language.

When make fails me for personal stuff, I switch to ninja [1]. The Chromium people use it in their Bazel-like build system. A hidden gem I recently discovered is doit [2]. I found this one incredibly helpful when I had a build with tons of 1:N, N:1, N:M dependencies.

[1] [https://github.com/ninja-build/ninja](https://github.com/ninja- build/ninja) [2] [http://pydoit.org/](http://pydoit.org/)

<comment><USER2> Thanks for the suggestions! That "doit" looks like it's simple enough for my fairly pedestrian needs. I wonder if my aversion to Make is that I don't spend enough time thinking/making Makefiles, but having something a little friendlier and simpler -- at the cost of ubiquity/portability -- might be the kind of training wheels I need.

Edit: FWIW, I posted doit to r/python and someone suggestion Snakemake, which also looks excellent and well-maintained: [http://snakemake.readthedocs.io/en/stable/](http://snakemake.readthedocs.io/en/stable/)

</comment></comment></comment><comment><USER4> Buck has been open source for a while! It's especially popular among larger companies who have a ton of mobile developers contributing to their apps, but I'm not sure if FB has ever publicized who exactly is using Buck. Other companies have been contributing to the Buck ecosystem, too, though, like [https://github.com/uber/okbuck](https://github.com/uber/okbuck)

<comment><USER5> It looks like they are starting to put together a list of who is using it:

[https://buckbuild.com/about/showcase.html](https://buckbuild.com/about/showcase.html)

</comment></comment><comment><USER6> This looks like a clone of Google's Blaze/Bazel: [https://bazel.build/](https://bazel.build/)

<comment><USER7> Buck was started after former google employees at facebook wanted to use something like blaze (ended up being called bazel). Kinda like a lot of other things they copied from google at facebook. Dremel -> presto, etc.

<comment><USER8> What are some other things apart from dremel?

</comment></comment></comment><comment><USER9> > "Buck is a build system developed and used by Facebook."

I have really, really grown to resent this culture of proud and unabashed cargo-culting that we've arrived at in the open source world. Why is this the first sentence describing a new project? Why do we need a Facebook™-approved build system? Does that somehow make it better than the others? And why does Facebook need their own build system? Was the existing ecosystem technically insufficient for them, or was the issue a legal one?

Whenever I make this point in dev circles, someone will reply, "They serve X amount of visitors a day, so they must know something!" Well, they also have a firehose of ad money pointed at them 24/7.

<comment><USER10> It does actually make a difference. Contrast:

> "x is a build system developed by me as a side-project that I might drop at > any time, and its only production use is to compile itself and a hello world > app"

Not to say people's side projects aren't useful, but there's only so many hours in a day, and there are thousands and thousands of open source projects, so you need some way to evaluate what's worth looking at. Knowing it has more than one person behind it, some time in field (so it's not 0.0.1 alpha), and is actively being used (you're not writing the first production code using it) goes a long way to separating it from the pack.

<comment><USER11> This does not logically follow. Why does facebook know best what kind of build system is suitable for my needs, given that I'm probably nothing like facebook? Why does George Foreman know how I want my grill?

I understand the human need to optimize attention, use basal heuristics to weed out unattractive options, and nurture a need to belong, but this is not logic. It's a rationalization.

It's also why this works, and why facebook (and every other major tech player) does it. It's a brilliant marketing and recruiting tool and a way to insert influence under the guise of open benevolence.

Hidden out there is probably a better tool for your needs. But now you'll never find it.

<comment><USER12> > I understand the human need to optimize attention, use basal heuristics to > weed out unattractive options, and nurture a need to belong, but this is not > logic. It's a rationalization.

There is an underlying logic though when you frame it in as a time vs reward problem. I _could_ spend a few months evaluating all of the various build tools out there and find the perfect fit for my team. Or I could spend a few days evaluating the projects with the most support (be that large companies, large communities, whatever). I'll concede that I can't guarantee it's the _perfect_ fit, but it's likely good enough when you compare the opportunity costs.

</comment></comment></comment></comment><comment><USER13> Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems.

We've got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them.

Maybe I'm just being bitter because I've had a bad experience, but it's been a maintenance nightmare for us in the office.

<comment><USER5> When Buck was created (my team created it!) there wasn't anything that supported what Facebook needed in a build tool. There still really isn't as all the Blaze work-a-likes are focusing on various different needs.

I would argue Buck actually helps to _solve_ what you are concerned about. At Facebook, everything builds with Buck (and Google with Bazel I hear)...which means you learn it once and you know it for your Objective-C library, your Android app, your Cxx service, your python scripts, etc. It really helps to standardize on a build system, and at many companies you can only do that if it supports windows/mac/linux, it supports many languages and platforms, is fast, and is easy to pick up. Buck is all of those things.

<comment><USER14> > At Facebook, everything builds with Buck

Looking at [https://github.com/facebook](https://github.com/facebook) you seem to be using all sorts of build tools...

<comment><USER15> What Facebook uses internally in their monorepo and what they publish to open source for external consumption doesn't have to be the same build tool.

Facebook uses fbshipit ([https://github.com/facebook/fbshipit/](https://github.com/facebook/fbshipit/)) to take slices of their monorepo and publish them to GitHub.

</comment></comment></comment></comment><comment><USER16> My name is Michael Bolin and I created Buck.

When I started the project, Buck had one specific goal: to make Android builds faster ([https://youtu.be/CdNw6mRpsDI](https://youtu.be/CdNw6mRpsDI)). At the time, the recommended way of building Android (from Google) was to use Ant. So when someone points to Buck as an example of "creating competing tools more often than persisting with and improving existing ones," I'd like to point out that you can't fix Ant if these are your issues with Ant:

* It is unsound. * Because it is unsound, it is irreparably slow. * It uses XML as a build language.

Yes, in July 2012, there were a number build systems on the market (though Bazel was not one of them, but Pants was), and none of them focused on building Android. And even if they did, few (if any) software companies were building an Android app as large as Facebook, so it was unlikely that anyone else was going to design for our scale.

It also wasn't just about build times, but about how I wanted to see us organize code in our repository. At the time, there was a flat list of folders in the Android repo, each called lib-something. This drives me insane because you inevitably end up with two (or more!) people creating com.facebook.common.StringUtils, each in their own lib-something. (It's also annoying to `ls` this "lib-" directory over time.)

In contrast, Buck/Bazel encourage the use of a unified tree, but still encourage fine-grained modularization (which is key as your build graph gets very large). This has been shown to scale to extremely large monorepos at both Facebook and Google.

Finally, by having total control of the build system, we were able to build in all sorts of cool tricks to build Android very fast, both in the large and in the small: [https://youtu.be/Y9MfGS3qfoM](https://youtu.be/Y9MfGS3qfoM). I don't think there is any other build system we could have decided to work with at the time to achieve these gains.

Buck has since evolved to build everything else at Facebook. This is not because the Buck team set out to conquer the world, but because people internally wanted the benefits of Buck for their builds. Building an alternative toolchain to xcodebuild was a mammoth effort (and one for which I take no credit). Having one build language for a heterogeneous collection of programming languages in a monorepo is no small feat.

Finally, to the people who believe "The big guys want developers locked into their ecosystems," I have news for you: the Buck team is not offended if you use Bazel, Gradle, Make, or anything else. Buck is open source because we wanted to share it with the community, not dominate it. Like many of you, people are excited to show their work and learn from others.

<comment><USER17> I think when you say "make Android builds faster", you mean "make Android application builds faster" \-- as opposed to making Android operating system builds faster. Those are two very different things, and for the uninitiated the casual use of language here is confusing. The Android operating system has never been built with ant, but historically was built with make until around Android N when that team started migrating to ninja-based builds instead.

<comment><USER18> I got confused by the exact same language 5 years ago when one of the Apache Groovy project managers (before it joined the ASF) started repeatedly saying "Google have now chosen Groovy and Gradle for building Android." I didn't know if they meant building Android at Google, or as the default build system shipping with their (then) new Android Studio tool.

</comment></comment></comment><comment> dyu- Buck is a great tool but doesn't work on windows, where bazel is now starting to support. So for crossplatform builds, either GN or bazel.

<comment><USER15> The only thing that I'm aware of these days that doesn't work on Windows is C++ code (but it works if you are building for Android on Windows). It's even covered in the getting started guide: [https://buckbuild.com/setup/getting_started.html](https://buckbuild.com/setup/getting_started.html)

<comment> dyu- Yea that's what I meant for crossplatform builds when I compared it with GN (c/c++ only, production-ready) and bazel (multilang, unstable).

Are you a member of the buck team? Your new account only has activity on this submission.

</comment></comment></comment><comment><USER19> Wow, so many build systems got mentioned here, when do people have the time to check them all out? I stick with gnu make because that's the evil I know, not because its the best tool imaginable...

<comment><USER20> Not everyone here is an expert in a particular system yet. If a build system runs 20% faster than what you're currently using, and you plan on using it for a good few years, the overall time saved is not insubstantial.

</comment></comment><comment><USER21> Or just use Nix as your build system.

<comment><USER22> Surprised no one else has mentioned nix, because this seems very much inspired by it. As someone who uses nix extensively this is interesting but doesn't seem as powerful or general.

</comment></comment><comment><USER23> Can somebody compare this to Gradle?

I mean somebody who has actually used both of them (and not read some versus blog posts).

<comment><USER5> I think the best people to speak to this would be the Uber folks, as I believe they still use both via okbuck ([https://github.com/uber/okbuck](https://github.com/uber/okbuck)):

[https://eng.uber.com/ios-monorepo/](https://eng.uber.com/ios-monorepo/)

</comment></comment><comment><USER24> I would recommend gn and ninja. It's the chromium build system. The make file is generated in less than a minute with gn, and ninja does a good job with incremental builds. It's also been around for a few years so it's been proven.

</comment><comment><USER25> Is there a watch command to detect file change and kick off the build steps?

<comment><USER5> Buck has a daemon that does it automatically. Often when you go to build it takes 0 seconds because the daemon has already done it before you get to it:

[https://buckbuild.com/command/buckd.html](https://buckbuild.com/command/buckd.html)

Note the daemon is automatically started when you `buck build`.

(disclosure: my team created Buck when I was at FB)

<comment><USER15> Although the daemon doesn't automatically build things. Buck does use watchman ([https://github.com/facebook/watchman](https://github.com/facebook/watchman)) to watch files though, and it has a way to run commands when files change: [https://facebook.github.io/watchman/docs/watchman- make.html](https://facebook.github.io/watchman/docs/watchman-make.html)

</comment></comment></comment><comment><USER26> Tools like Make are also useful for simple data analysis workflows, and I'm curious to hear any thoughts from any Buck users as to whether it would be useful in those cases too.

</comment><comment><USER27> Great! There's also a Lua-based build tool.

[https://news.ycombinator.com/item?id=13867347](https://news.ycombinator.com/item?id=13867347)

</comment><comment><USER28> Just what we need.... another build tool!

</comment><comment><USER29> I sometimes suspect that the build tool ecosystem would be very different if only Makefiles allowed soft tabs.

</comment><comment><USER30> Wonder if this can/will replace CMake for cross platform builds.

<comment> dyu- Doesn't support windows. You're better off with bazel or GN.

<comment><USER31> How do you in 2017 come up with a build system that doesn't even run on Windows.

<comment> dyu- They made buck for themselves where their infrastructure runs on (*nix). Google's internal build tool (before bazel) was the same. Now chromium's GN build tool was made for their product that was targetted to run everywhere, which is why windows support is good.

</comment></comment></comment></comment><comment><USER32> Do such tools have any quality/security standard?

</comment><comment><USER33> Does not support Swift at the moment.

<comment><USER15> It does, although it may not be 100%. I've seen lots of PRs going by that fix problems with Swift support.

</comment></comment><comment><USER34> Nice build output. Unless you want to look over it afterwards that is.

<comment><USER5> A couple of quick notes:

* It also writes build output to an output directory

* It detects a tty and does the right thing, so on CI you get a linear log

* In the output directory it also includes timeline graphs that can be loaded in Chrome's devtools traceview ([https://github.com/catapult-project/catapult/blob/master/tra...](https://github.com/catapult-project/catapult/blob/master/tracing/README.md) and in Chrome proper).

* The tracing can be viewed live [https://buckbuild.com/command/server.html](https://buckbuild.com/command/server.html)

(disclosure: my team created Buck when I was at FB)

<comment><USER34> Sweet! Looks like a great project, congrats!

</comment></comment></comment><comment><USER35> Anyone care to compare Buck vs pants vs Bazel/Blaze?

Or perhaps write out your individual experiences mentioning:

1) Team size

2) Repo size

3) Repo programming language distribution.

4) development/Testing/build/publishing strategy

5) Of course, the actual experience

</comment><comment><USER36> So much complexity to put some pictures on a screen and have people click 'like'.

It's dizzying.

I wonder if build-system complexity is an artifact of reducible complexity in other areas.

Perhaps the next time we develop a language, it should comprise of it's own build system that doesn't require any configuration, or rather minimal. To the point wherein we didn't need to think that much beyond the obvious.

<comment><USER37> I think a few people had that same thought, and then invented Golang. Love it or hate it, building a typical go app, or even a suite of apps, is pretty darn simple.

If you can get by using only go for everything, you'll have a great time. But complexity starts to become unavoidable when requirements move beyond single- language ecosystems. At some point simplicity can end up costing more.

</comment></comment><comment><USER38> How come this tool became no.1 trending on HN?

</comment><comment><USER39> I agree with the comments in this thread, and I add that Facebook knows fanboys are stupid and there are a lot of them, so they try to take advantage of it.

> Buck: A high-performance build tool

And in the title you read "a fast build tool", like yarn, as soon as it was released it was the faster one.

F: let's use yarn/buck G: why? F: cause it is faster G: Did you already tryed it? Did you measured or benchmarked it? F: No, but Facebook claims it is fast, come on!

By the way, sometimes yarn does not work and you need to add a file to manage it. Furthermore facebook is using the npm registry, do they pay for it or support it?

Other than that, thanks to Facebook to bring awesome tools to the public, like React.

<comment><USER40> For my needs yarn was a drop in replacement for npm and it _is_ faster, 5s vs 17s for a fresh install but critically it's reproducible, I get the exact same output in node_modules every time I run it and that _alone_ was worth the switch.

As for using the npm registry (by default) so what? Why would the npm folks care, MS uses it as well with vscode ans its automatic resolution.

<comment><USER41> Agreed that yarn is faster and reproducibility is critical, but in case you aren't aware, you can have reproducibility with npm too by using the "npm shrinkwrap" command.

<comment><USER42> Updating a single package version in a yarn.lock file is much easier than updating a single package version in an npm shrinkwrap file, in my experience. With yarn it's just a single command. With npm shrinkwrap, you have install everything from the current snapshot, then install the package you want to update, then run npm prune, then regenerate the shrinkwrap file, then look through hundreds of lines of mostly irrelevant diff to make sure that it did what you wanted it to.</comment></comment></comment></comment>


Verisign announces 10% .net price hike on February 1, 2018 - <AUTHOR> http://domainnamewire.com/2017/07/28/verisign-net/ <comment><AUTHOR> This has been happening for a few years now: "Verisign announced an increase in the annual fee for a .net domain name registration from $7.46 to $8.20., per its agreement with the Internet Corporation for Assigned Names and Numbers (ICANN). .Net price is now higher than the .com price that is frozen at $7.85 until at least 2018.

I seems that this increase has become an annual tradition now."

[https://onlinedomain.com/2016/08/01/domain-name-news/net- dom...](https://onlinedomain.com/2016/08/01/domain-name-news/net-domain-name- price-goes-10-february-1st-2016-76-since-2012/)</comment>


The Android which really made it: Openmoko reopen now - <AUTHOR> http://www.openmoko.com/store.html Openmoko is a project which encompasses two related sub-projects, with the combined aim of creating a family of open source mobile phones.[1] The project was founded by FIC.
The first sub-project is Openmoko Linux, an open source Linux based operating system designed for mobile phones, built using free software.
The second sub-project is the development of hardware devices on which Openmoko Linux runs. The first device released was the inconsistently-named Neo 1973 or Neo1973[2][3], which was followed up by the Neo Freerunner on the 25th of June 2008.[4] Unlike most other mobile phone platforms, these phones are designed to provide end users with the ability to modify the operating system and software stack. Other Openmoko supported phones are listed here. <comment><USER2> I'm definitely interested in hearing about people's experiences with these. I had pre-ordered one of their development phones last year, but gave up because of the constant delays.

I kept up with the dev list for awhile, but there were a lot of complaints about the hardware - battery life in particular, so I stopped paying attention.

<comment><USER3> The one thing I'm a bit weary about is their build environment. Last I checked they use OpenEmbedded, which to put it plainly, blew chunks last I tried to use it. After 48 hours of not sleeping I gave up and switched to OpenWRT's new buildroot-ng which I found significantly easier to use.

<comment><USER4> I hear you, I spent all WEEK fighting with OpenEmbedded. Painfully, it is better than LTIB. Actually there is a sub-set of OE called Poky that is really solid. OE's problem is that the packages vary in quality - primarily in their ability to compile on multiple platforms - Poky picks the betters ones and has fewer platforms, it works very well.

</comment></comment></comment><comment><USER5> So wait, does the new device run Android? Their site doesn't lead me to believe it does, and google searches only return stories of people failing to run Android on the last one.

<comment><USER6> The software stack was developed long before Android was around. There's a good graphic describing the software here: <http://wiki.openmoko.org/wiki/Category:Software>

I believe the are enabling android to run "beside" their stack.

<comment><USER4> Correct, OpenMoko uses the CacaoVM with GNUClasspath for Java - although it is primarily not a Java device. Android is running the DarvickVM which is not actually Java, and runs a Java syntax on top of it. Though the code is compatible, byte code is not, so binary packages for OpenMoko or Android will not run on each other. Thus the two stacks need to be side by side, or you need to rebuild all the packages from one for the other.</comment></comment></comment>


R Passes SAS, but Python Leaves Them Both Behind - <AUTHOR> http://r4stats.com/2017/02/28/r-passes-sas/ <comment><USER2> I'm glad to see the quick convergence on Python. I've evaluated Python every ~2 years since 2006 for "data science" tasks (machine learning, statistics, data munging, and visualization). I'd argue that Python only properly covered this full data science stack 1.5-2 years ago. R covered this stack adequately probably around 2011-2012. Matlab had this before 2005.

What makes Python a superior language to Matlab and R is the ease of software development. It's an easy, pleasant language to work in, and I trust it for production tasks (I've written production R code and it's fairly hard to read and fragile).

What's even better is data science is moving 100% into Python 3 (from 2) by 2020:

[http://www.python3statement.org/](http://www.python3statement.org/)

<comment><USER3> If you work in a team mixing data engineers and data scientists then python has been a superior choice for a decade as the different team members are all using the same language to build the platform and to use it.

We've had a lot of success weaning people of R and MATLAB in finance (so replace "data scientist" with "quant"). Of course if you work in a field that doesn't have the libraries and can't build them in house then your mileage will certainly vary.

<comment><USER4> Off-topic, but what is a "data engineer"?

<comment><USER5> I'm sure someone can come along with a better description, but it's kinda like devops/sysadmin but specifically for data storage and access.

You could also look it up...

<comment><USER6> At some point, people realized that 90% of data science work was building pipes and keeping them clean. And then data engineering was invented so that the data scientists wouldn't have to get their hands as dirty. :)

</comment></comment></comment></comment></comment><comment><USER7> There is a question regarding the definition of "data science jobs." The author explains his methodology in a lengthy report [http://r4stats.com/articles/how-to-search-for-data- science-j...](http://r4stats.com/articles/how-to-search-for-data-science- jobs/)

The issue is what is "data science" really? In what respect is it different from traditional statistics and data analysis and not just a new buzzphrase?

Probably many jobs using SAS could be considered "data science" but don't use the specific buzz words and phrases that the author specifies in his methodology to identify "data science" jobs. Thus, the headline that "R Passes SAS" could be inaccurate, except in the sense that R is more popular among statistics and data analysis jobs that use "data science" buzzwords and phrases.

<comment><USER8> SAS is also a huge iceberg, without much in the way of open source culture that lends itself to visibility. A lot of SAS happens behind closed doors at megacorps.

<comment><USER9> Also notable that so many new shops are foregoing it entirely. SAS, and its price tag, is a holdover from the days when 'analytics' was an afterthought for companies looking to maximize profit.

Now that much less mature companies are realizing the value of 'analytics' (I hate that word) SAS's cost doesn't really make sense.

<comment><USER10> What word do you prefer to 'analytics', if we are talking about taking data and analysing it to extract insights?

This does not have to involve machine learning, and "pattern recognition" is an academic term (and might be confusing for laymen).

<comment><USER11> Why not just "analysis"?

Business people seem determined to invent new jargon when our current vocabulary is sufficient.

<comment><USER9> The euphemism treadmill makes my raises bigger.

</comment></comment></comment></comment></comment></comment><comment><USER12> I recently finished grad school and accepted a data scientist job a couple weeks ago in part because the job description mentioned expertise with Julia as one of the preferred qualifications (it's rare to see a listing that mentions Julia). It's the language I used for the bulk of my research over the last four years, and has been improving rapidly since it was released. I like Julia a lot more than Python, and I hope it continues rising in popularity. I think once it hits v1.0, we'll begin to see a lot more companies adopting its usage for data science, statistics, and machine learning.

<comment><USER3> > I think once it hits v1.0, we'll begin to see a lot more companies adopting > its usage for data science, statistics, and machine learning.

I don't. It doesn't have the incumbency of R, the use in other areas of programming of Python, or a company actively marketing it like MATLAB. It's not 5x or 10x or whatever good enough than the alternatives to assert itself in the playing field.

If it means you get your work done using it, be all means use it. But I think it will stay around clojure levels of use in data science, statistics, and machine learning.

<comment><USER13> Once you can compile a julia app- front end, back and probabilistic prog/ML to web assembly and have it run in browser and mobile, it will skyrocket in popularity.

<comment><USER3> Why? The only current benefit of Julia afaict is the tracing jit. If you run the tracing jit on web assembly then it's giving up most of its performance benefits. And Python could be built on web assembly as well.

But who knows. Weird things seem to become popular despite all the negative points.

<comment><USER13> It does not have a tracing JIT, and its speed is by far not the only benefit. See link below

It can precompile very fast code before runtime.

Python will require an interpreter and or hefty runtime.

[https://discourse.julialang.org/t/julia-motivation-why- weren...](https://discourse.julialang.org/t/julia-motivation-why-werent-numpy- scipy-numba-good-enough/2236/10?u=mikeinnes)

<comment><USER3> Forgive me, it's not a tracing JIT but just LLVM's JIT.

Precompiling in Julia is extremely not-straight-forward. You would think you just use --compile and it would work; but it doesn't at all.

Also, at ~850kb, Python's runtime is not that hefty. It's intended to be embedded and while it's quite a bit larger than lua's 200kb, but smaller than libjulia's 16mb.

<comment><USER14> Right, It can currently precompile to some extent, but full source-to-binary- blob-compilation is on the roadmap. See here: [http://juliacomputing.com/blog/2016/02/09/static- julia.html](http://juliacomputing.com/blog/2016/02/09/static-julia.html)

Julia's runtime includes its compiler and full huge standard lib, but of which are eventually going to be split off, IIUC.

The former because of static compilation potential and the latter into modules that can be included piecemeal.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I'm surprised that the author combines "the C languages" saying that most adverts that mention any of C/C++/C# mention all three. In my experience there is a large difference between companies searching for C# developers and those searching for C/C++. After blurring this distinction he concludes that R and Python are "very different languages" while I consider them to be largely overlapping.

<comment><USER16> Agreed.

So far in my search, C# leans toward Microsoft shops seeking C#/.NET whereas C/C++ has been companies searching for embedded software roles.

<comment><USER17> Mostly agree, but I've also seen a fair bit of C/C++ skills associated with jobs involving *nix development environments. I've rarely seen C++ associated with embedded jobs (even though I've read that it can certainly be used if care is taken to avoid things like dynamic dispatch, etc)

<comment> charles-salvia C++ is very big in finance and game development.

</comment></comment></comment></comment><comment><USER18> I hate these sort of comparisons. You've got R, Python, SAS... okay, those are sort of similar. Then you've got Java and "C, C++ or C#," and man, including C# with C/C++ is... fraught. Then you've got Hadoop, Spark, Hive... okay, those are all kind of different from what we've had so far. Now you've got Tableu and RapidMiner. Uh. In the second chart, "Microsoft" is included as a keyword. Okay. It's just... comparing apples, oranges, bananas, grapes and pears. What's it supposed to tell us?

<comment><USER19> "Microsoft was a difficult search since it appears in data science ads that mention other Microsoft products such as Windows or SQL Server. To eliminate such over-counting, I treated Microsoft different from the rest by including product names such as Azure Machine Learning and Microsoft Cognitive Toolkit. So there's a good chance I went from over-emphasizing Microsoft to under- emphasizing it with only 157 jobs."

Read the methodology, Luke.

<comment><USER18> Okay, but what does that mean? Microsoft Cognitive Toolkit is like Tensorflow, which is included as an item on the list. Azure Machine Learning is something you can script with R or Python, and allows you to create APIs for predictive use on Azure. What good does lumping those together do? And what does it tell us that some things that are basically an R/Python library are less popular than R or Python themselves? It's this weird, uneven mix of things. Some are programming languages, some are libraries or frameworks, some are end-user products like Tableau.

<comment><USER20> This is pretty much what data science in the real world is like.

Define the question you are interested in (in this case, a somewhat reasonable attempt to compare R/Python/SAS) and the put other things in blobs with a note that says _this is what this blob is. Enjoy_.

<comment><USER19> Bingo. Thanks. I was losing (patience|interest).

</comment></comment></comment></comment></comment><comment><USER21> Nice data munging out of Indeed.com here. The article author gives a detailed description of searching Indeed in a write-up linked from the original article as well ([http://r4stats.com/articles/how-to-search-for-data- science-j...](http://r4stats.com/articles/how-to-search-for-data-science- jobs/)).

Just playing around with the search terms from that second linked article is also interesting - it would appear that many terms ("machine learning", "data science", "predictive modeling", some others) show that Amazon has the largest number of job listings from a single company - for "machine learning" Amazon shows 1706 listings out of 12499 or almost 14% of _all_ listings . . . The way Amazon also pops out in other data science term searches is also interesting - at least in their job listings, Amazon seems to really be attempting to slurp up candidates with deeper data and stats skills.

For some time I have been somewhat cynical about data science. My impression has been that much of what has been pushed as data science jobs is thinly veiled data reporting gigs (just plain old business intelligence). While I still think data science is over-hyped, I think I need to reconsider just how critical it will be as a knowledge base or skill set. While there may not be a large number of deep learning jobs out there, the expectation that a data hacker can be expected to perform a linear or logistic regression against a set of gathered and cleaned data may be closer to fizz buzz than I previously assumed.

I am teaching an introductory programming class (using Python) this semester and students are definitely focused on data science as a career track.

</comment><comment><USER22> R's data analysis libraries are still far ahead of Python. Dplyr, Shiny, etc. So much stuff is still in built in R.

Places where I still use R is its easy to use statistical functions, handling large amounts of missing data, etc.

</comment><comment><USER23> I once worked on a piece of software communicating with a SAS instance (doing live decision management), but everything about it seemed sketchy. No one using it really liked it, and its internals always appeared like a blackbox to me. Also, either it is terribly engineered or the devs working with it were just bad - we wanted a JSON-based REST API, but they said that it's "not possible with SAS", so we fell back to badly organized HTTP calls with XML.

Does anybody have some insights about internal quality and code "health" in SAS?

<comment><USER9> Anecdotal, but our SAS decision support environment went down Friday. I can report back after the post-mortem if you like.

<comment><USER23> Yeah, would surely be interesting.

<comment><USER9> Nothing exciting to report. It was a resource-sizing problem and they didn't adequately separate prod and dev environments. Someone choked the dev and the prod went down with it.

<comment><USER23> Thanks anyway for the insight!

</comment></comment></comment></comment></comment><comment><USER24> This is a sample of non-data-science job postings, which mention buzzwords like "big data".

Java is not a popular language for data analysis.

</comment><comment><USER25> Python suuuucks.

<comment><USER26> This attempt to eli5 could be improved.</comment></comment>


Understand your body to get more energy scientifically - <AUTHOR> http://www.bakadesuyo.com/2016/01/how-to-get-more-energy/ <comment><USER2> "Just by betting on west coast teams in every Monday Night Football game where they played east coast teams you'd beat the point spread 70% of the time. NFL teams that crossed three time zones for a game "were twice as likely to be beaten by a lower-ranked opponent in the tournament's first round."

Those are conflicting conditions (Monday Night Football is not a tournament with rounds), so this data (at least) is suspect.</comment>


How to be an Indispensable Programmer - <AUTHOR> http://www.farbeyondprogramming.com/2010/07/41-how-to-be-an-indispensable-programmer <comment><USER2> Weird, weird list. Smile? Be a friend? Eh? Is this a social club?

My list is a lot shorter: (a) write lots of good code out of personal inclination (rather than being forced by code reviews or because you are being nagged or whatever) and (b) be able to troubleshoot your way out of a paper bag.

I really don't care if you smile at me or not.

<comment><USER3> _Is this a social club?_

No, but I would prefer not to work with a douche-bag.

However, if you're only referring to the strict subset of traits that make you a good programmer (and nothing else), then yes I agree.

<comment><USER2> A person who doesn't smile, or isn't overly friendly is a douche-bag? I think you have your definitions mixed up. Introverts, reserved people, naturally taciturn people, super-shy people, people from cultures that don't show their teeth at every opportunity - they are perfectly fine people and can be a joy, a _joy_ to work with.

People are great to work with when the work just "flows" around them. Their personalities are (mostly) orthogonal with that. It doesn't make them assholes. Come to think of it, the assholes are more likely to smile. YMMV.

<comment><USER4> _A person who doesn't smile, or isn't overly friendly is a douche-bag?_

Generally, yes.

It's human nature to be judgmental. You can disagree with it all you'd like, but ignoring it will directly impact you in a negative way.

It's why I try to go out of my way to smile and ask someone about themselves every time they come by to ask me a question / chat / whatever, even if I don't feel like it.

Such positioning may seem fake, but I feel it's "fake" in the same way wearing clothes is "fake". You can disagree with wearing clothes, but running around without pants won't win you much respect.

<comment><USER2> Yeah sure, it might affect how much people like you. Unfortunately, when you have to sit around a table and decide who has to be laid off, I am sorry to say I have never known likeability to be a consideration. If someone is nice you will feel worse about having to let them go, but you are never going to get rid of your grumpy hero programmer to keep the slow-coding nice guy. I can say this from experience.

The OP was about being indispensable; and as I said, the person who is indispensable is the one the business can least afford to lose. There are occasionally other considerations, but they are all done without reference to most of the items on that list, at least from what I have seen.

<comment><USER4> Good point.

</comment></comment></comment></comment></comment></comment><comment><USER5> Better to be a dispensable programmer. Teach others and share knowledge and understanding and make the team as a whole "Built To Last" ([http://www.amazon.com/Built-Last-Successful-Visionary- Compan...](http://www.amazon.com/Built-Last-Successful-Visionary- Companies/dp/0887307396)).

</comment><comment><USER6> You only have people you "can't lose" when the whole team is mediocre. If you have at least couple great programmers they will usually have enough drive to learn every aspect of the project. And they will be able to pick up anything in days even without much knowledge sharing.

<comment><USER7> I've found it doesn't always work that way. For instance, we have a legacy homebrew billing system that's a Lovecraftian nightmare of procedural PHP batch pipelines. We're all eagerly looking forward to just replacing it wholesale, but in the meantime nobody delves into it, partly to preserve our sanity and partly because nobody wants to be marked as "the guy who knows it best" and condemned to maintaining it. All the original developers on that part of the system quit months or years ago, but we have the last of them on retainer to recover it from its failures. _That's_ the guy we couldn't lose.</comment></comment>