BetterConnect+ app – all that you need to achieve your chronic-health goals - <AUTHOR> https://play.google.com/store/apps/details?id=user.com.hlthee <comment><AUTHOR> BetterConnect+ puts at your fingertips, all that you need to achieve your chronic-health goals.

BetterConnect+ technology enables Patients to manage their chronic conditions by keeping track of personalised goals, health vitals and medicine adherence via an integrated cloud-based mobile application.

BetterConnect+ is a free download. If your doctor has not yet subscribed to BetterConnect+, you could still use our app for self-management…

Features: #Health Coaching: You, your doctor and care manager co-create actionable care plans to help you achieve better health outcomes. Your care team (doctor, care manager) monitors your health data, daily progress and keep you motivated to achieve your health goals.

#Daily To-do list: See your daily to-do list outlining the health activities to be done for the day. Simply tap on the activity to say that it is done.

#Log Health Vitals: Log your health vitals such as Blood Pressure, Blood Sugar (pre-meal, post-meal), HbA1c, Lipid Profile, Height, Weight and keep track of these numbers via line charts and bar graphs.

#History: See all your health data logged neatly summarised in the form of weekly, bi-weekly, 30 days, 90 days period line charts and bar graphs.

#Track Performance: Analyse the trends in your health data; see the values that have been above safe zone, below safe zone or within a safe zone. Get to know your areas of improvement and plan ahead accordingly.

#Chat Support: BetterConnect+ app has an integrated, secure chat platform. You can send instant text-based messages to your care manager, share videos, images or files for quick support. Your care manager or doctor can also create an exclusive chat group that includes your doctor, your care manager and you.

#Medicine Adherence: BetterConnect+ app lets you set medicine reminders for your medicines. Interactive pie charts help you determine your adherence rate for each medicine in your routine.</comment>


Facebook Still Letting Housing Advertisers Exclude Users by Race - <AUTHOR> https://www.propublica.org/article/facebook-advertising-discrimination-housing-race-sex-national-origin <comment><USER3> The text of the law[0] is surprisingly clear that FB's acceptance of these ads is illegal (unless I'm missing something big).

        As made applicable by section 3603 of this title and except as exempted by
        sections 3603(b) and 3607 of this title, it shall be unlawful—
        ...
        (c) To make, print, or publish, or cause to be made, printed, or published
        any notice, statement, or advertisement, with respect to the sale or rental
        of a dwelling that indicates any preference, limitation, or discrimination
        based on race, color, religion, sex, handicap, familial status, or national
        origin, or an intention to make any such preference, limitation, or
        discrimination.

[0] [https://www.law.cornell.edu/uscode/text/42/3604#c](https://www.law.cornell.edu/uscode/text/42/3604#c)

<comment><USER4> See, I didn't read it that way.

"…that indicates any preference, limitation, or discrimination…"

If the ad itself does not mention the preference, then it does not seem to be covered by this clause.

Would it not be analogous to advertising the property to a particular racial or religious group, such as a church bulletin board?

The distribution of the ad is being targeted, but the ad itself does not indicate any preference. It seems as if the latter is the only thing that is deemed illegal by the law.

Am I reading it correctly?

<comment><USER5> I agree it doesn't seem to violate the letter of this particular law.

But it's close to being the digital version of redlining. Before the Fair Housing Act real estate brokers would show certain houses only to white clients and other houses only to clients of color. That was explicitly deemed illegal. If you see real estate brokers as a medium through which sellers would advertise their houses I don't see how this is much different.

<comment><USER6> There is a huge difference.

1\. Real estate was not easily searchable in the past.

2\. An ad is at least one degree away from a broker in this process. The broker works directly with the buyer and seller while an ad passes leads to brokers.

<comment><USER7> Sometimes I think what real estate agents can't say goes too far.

[https://realestate.usnews.com/real-estate/articles/what- your...](https://realestate.usnews.com/real-estate/articles/what-your-real- estate-agent-cant-tell-you)

The three that stand out are that a real estate agent can't mention crime rates, school ratings, or that a house may not be wheelchair accessible - <USER2> if the buyer asks.

<comment><USER8> That's a bit odd since now all that data is available to the public --why bind the RE agent's hands in this matter? I mean, perhaps in the past they had "insider" knowledge of those particular statistics but not today.

</comment></comment></comment></comment></comment></comment><comment><USER9> Recognizing race does not equal being racist at all, imho.

I don't want to live in a society where I can't objectively (in no bad way whatsoever) acknowledge trait differences, whether they be skin colour or hair length.

<comment><USER10> Sucks to be a black person in such a society, though. For no reason other than their skin color they are lumped in with a group of people lower average prosperity and then are denied access to resources and systems because of this grouping. Especially when these disparities are themselves caused by a history of deliberate oppression. How convenient that we get to continue to perpetuate inequalities that were themselves caused by the group in the majority. The grouping itself is a problem and produces false or misleading ideas about individuals.

Men are far more likely to commit violent crimes than women. Should employers and landlords be able to blanket deny access to men?

<comment><USER11> Employers and landlords should be able to deny access to anyone they please. It's their company and their property, after all.

<comment><USER12> It's absolutely morally indefensible to refuse services because of what someone was born as.

<comment><USER11> Any company or landlord who does such a thing will go out of business, since any clever competitor will snatch those great deals that those companies and landlords are missing out on.

<comment><USER13> That is ... not actually true. It'd be great if that's what happened, but we have several decades of discriminatory housing/credit policies that haven't put companies out of business. _Equifax_ started primarily as a tool to help people discriminate.

</comment></comment></comment></comment></comment></comment><comment><USER14> Can any attorney with knowledge of fair housing weigh in on this? Law quotes states that the ad cannot say these things, but the publishing of an ad in a medium targeted based on these seems like a relatively new ground, since the ad itself is likely fine, but how it is distributed is definitely not in the spirit of the law.

In finance, I'm fairly sure zip+4 is off limits in many pricing models for this exact reason - it is too specific. However, I'm not aware of anything like this in advertising publishing that a given ad has to have a chance of being seen regardless of the protected categories.

Regardless of the law, it's definitely extremely unethical to do this.

<comment><USER15> It's not new ground, nor do I believe it to be necessarily unethical.

People can and do advertise in predominantly white settings or black settings, e.g. a church or a sports game or a magazine.

Advertising has always, always, always been a numbers game. Didn't advertise on billboards in the middle of Wyoming? Maybe because there was lower ROI than elsewhere.

</comment></comment><comment><USER16> Techmeme summary: _ProPublica: Ads for housing that exclude demographics are still being approved by Facebook, a year after a study highlighted the illegal discriminatory practice on Facebook_

</comment><comment> apk-d Is there a non-negligible fraction of ads that do this for this to be an actual problem? Or is it another article riding the wave of the media crusade against Facebook? Genuine question, I don't have a Facebook account and I live in a country rather separated from the racial discrimination concerns present in the US.

<comment><USER17> Facebook doesn't publish what interest categories and demographics go into their ads (aka you can't click on an ad in FB and see what led to it being shown to you).

But we're talking billions of dollars a year in ads, of which real estate is a respectable percentage (FB is very good at doing geographic targeting).

And you certainly also have these relatively unsupervised and opaque "interest categories" that are being presented to advertisers.

</comment></comment><comment><USER18> Someone explained to me a while ago, in New York State, it was illegal to discriminate on race, color, religion, sex, etc. for renting out apartments in 3+ unit dwellings.

As an owner of a single home, renting out the upstairs apartment, it was supposedly perfectly OK to discriminate based on those things.

I never dug into this, but if it is true, the question is: "Should Facebook ad tools facilitate such discrimination, even if it is not forbidden by law?".

<comment><USER19> It's this federal law the Fair Housing Act, not state law, that has an exception for smaller properties where the owner lives (New York may further extend federal protections). The exception only allows discrimination in not allowing someone to live there, it's still illegal to advertise in a discriminatory way.

[https://fairhousing.foxrothschild.com/2010/06/articles/fha-b...](https://fairhousing.foxrothschild.com/2010/06/articles/fha- basics/the-mrs-murphy-exemption-to-the-fair-housing-act/)

</comment></comment><comment><USER20> If people keep following the logical end of this, then facebook and google's entire business model is going to implode on itself.

All of online marketing is basically segmenting populations by various group traits. It says nothing about the individual, but as a marketer you think in those broad categories that maybe, just maybe different ages, races, locations might respond differently to ads.

<comment><USER21> Are you using the slippery slope fallacy to argue against the existence of federal protected classes?

<comment><USER20> Nope.

I'm just saying that if you remove the ability to target ads based on specific person characteristics, you remove a piece of what makes fb so valuable of an advertising platform (that is to target people so microscopically).

Just pointing it out.

<comment><USER22> The number of products to which such non-discrimination law applies to is vanishingly small though. It's not illegal, for instance, to racially target advertisements for flagship smartphones towards white people (since white people tend to be richer and thus have more disposable income), not that any marketing agency would do that in practice.

Completely avoiding bias in advertisement is an exercise in futility. Are you a toy manufacturer? Advertise on children's TV shows - not that such a marketing strategy states that adults will never buy the toys, or that the business of adults buying such toys for themselves is unwelcome. Are you a cosmetics manufacturer? Advertise in cisfemale interest magazines - not that such a marketing strategy states that noncisgender individuals will never buy cisfemale-targeted cosmetics, or that the business of noncisgender individuals buying such cosmetics for themselves is unwelcome.

<comment><USER20> > Completely avoiding bias in advertisement is an exercise in futility.

That's not the point of the ad system. The point is to optimize inventory + bidding. So you can bid on all of those -sure, but if you have the capability to break down children toy ads to children + to adults - you do it and have different strategies for both (broad based appeal to kids and buy-action to parents). You can be more precise with the ads + the spend so it makes sense to do it.

</comment></comment></comment></comment></comment><comment><USER23> Not to de-rail the thread, but man, FB's slide here has been _fast_. Just about 1 year ago we were talking about 'fake news' as a threat separate from FB. FB was still considered 'neutral' at worst, if not a 'good' thing.

Now? It seems like everyone hates them. Not that they are doing themselves favors at all, but them and Uber are downright villains now.

</comment><comment><USER24> They can just advertise to people who like Bing Crosby instead.

</comment><comment><USER25> And that's not all, I hear they're still letting make-up advertisers to exclude users by gender.

</comment><comment><USER26> Do these laws really yield results?

If somebody doesn't want to rent to or hire a person of a certain race they just won't. They may be forced to not be specific in their ad, but in the end they still won't call you back.

<comment><USER21> For a single person renting out one house, they will get away with it. But for an apartment complex, they can get investigated and have secret shoppers come in and then they get in trouble for not treating the two marker customers the same.</comment></comment>


Virool Banned from Google? - <AUTHOR> https://www.google.com/search?q=virool Seems like Google isn't too happy with Virool as their domain does not show up organically on the first page.... but then again, there is adwords! <comment><USER2> Anybody knows if this is YouTube or Sponsored Posts related?</comment>


Developer Is the Next Blue Collar Job - <AUTHOR> https://dev.to/stereobooster/developer-is-the-next-blue-collar-job-269b <comment><USER2> If you drop the pejorative classist connotations of "blue collar," it always has been in the sense that programming is a _craft_.

Some "blue collar" people make great money too. There are numerous skills in high demand in areas like welding, specialized construction techniques, etc. that can net you a six figure income.

</comment><comment><USER3> I agree. There are different requirements in software development jobs and some of them do require college education while others don't. It's a vast field now and not every job is the same. We just need to be careful not to look down at each other just because we assume someone's job needs less qualifications.</comment>


Show HN: Staffjoy V2, now open source - <AUTHOR> https://github.com/staffjoy/v2 <comment><AUTHOR> I announced two weeks ago that we are shutting down Staffjoy [1] and open sourcing our code. Last week, our primary V1 repo was submitted to HN [2]. Yesterday, I open-sourced our V1 microservice Chomp for computing shift scaffolds from forecasts [3]. I also also published our YC Fellowship application [4] and pitch decks [5] on our blog.

Today we opened the V2 repo of Staffjoy, which contains a microservice architecture, detailed here [6]. V2 was a monorepo, meaning that all of the code is in one repo. This is the largest and most sophisticated of our repositories.

You can learn about the difference between V1 (autoscheduling of hundreds of workers) and V2 (Excel replacement with text messages for small businesses) in our design journey blog post [7].

We are continuing to open source our last repos, which are mainly V1 microservices. Specifically the V1 Cron microservice, V1 mobile applications (iPhone + Android in React Native), V1 Scheduler microservice (our first scheduling algorithm), and the V1 Mobius microservice (which solves an assignment problem) will be open-sourced in the coming days.

If you have any questions - please let me know! I'm providing contract support for anybody wishing to deploy, modify, or customize Staffjoy code through Moonlight [8].

[1] Shutdown announcement: [https://news.ycombinator.com/item?id=13647382](https://news.ycombinator.com/item?id=13647382)

[2] V1 "Suite" [https://news.ycombinator.com/item?id=13730488](https://news.ycombinator.com/item?id=13730488)

[3] Chomp service [https://github.com/staffjoy/chomp- decomposition](https://github.com/staffjoy/chomp-decomposition)

[4] YCF Application: [https://blog.staffjoy.com/staffjoys-yc-fellowship- applicatio...](https://blog.staffjoy.com/staffjoys-yc-fellowship- application-5771c8a105cd#.lvnoezlpr)

[5] Pitch decks: [https://blog.staffjoy.com/staffjoys-pitch-decks-that- raised-...](https://blog.staffjoy.com/staffjoys-pitch-decks-that- raised-1-7m-15812018968#.5k08omn51)

[6] V2 Architecture: [https://blog.staffjoy.com/staffjoys-v2-architecture-9d2fcb40...](https://blog.staffjoy.com/staffjoys-v2-architecture-9d2fcb4015fd)

[7] V1 to V2 Design Journey: [https://blog.staffjoy.com/staffjoy-v2-ca15ff1a1169#.ttejeklw...](https://blog.staffjoy.com/staffjoy-v2-ca15ff1a1169#.ttejeklwn)

[8] Contract support - [https://www.moonlightwork.com/staffjoy](https://www.moonlightwork.com/staffjoy)

<comment><USER3> Phillip, I'm sure going through all this as a part of your shutdown isn't easy, but it's really great that you're taking the time to do it. I'm sure there are many who will benefit from making all of this open source. Many thanks and best of luck going forward!

<comment><AUTHOR> Thanks! Please reach out if I can be a resource too.

</comment></comment></comment><comment><USER4> We are sharing your sentiment that a lot of our user-facing errors could be limited by moving away from weak typing (current stack is Ruby). In hindsight, did Go and protobuf prove well, we are evaluating Go and possible Elixir as a sweet spot between static and dynamic typing.

<comment><AUTHOR> Yes. I would always use gRPC-gateway in the future. It's an amazing library. Check out the `protobuf` folder - we basically defined the whole api there in a language-agnostic way. For client libraries, you can autogenerate gRPC definitions quickly. For servers, gRPC-gateway provides a Swagger definition that meant that we always had 100% up to date API docs that include a Postman- style way to execute calls. The auto-generated API docs sped up front-end development so much.

I think that access to the docs requires logging in, so here are some screenshots: [http://imgur.com/a/R0AvB](http://imgur.com/a/R0AvB)

Jason Chen is using Elixer/Phoenix for his new project, by the way, and thinks that it's the future for Rails developers.

<comment><USER4> gRPC-gateway looks very attractive. Thank you for posting this for the rest of us to learn from, a brilliant effort for sure.

<comment><AUTHOR> Its documentation is horrible for getting started. Lmk if you have issues.

</comment></comment></comment></comment><comment><USER5> What are your thoughts on the re-write in hindsight, would you have done it differently looking back on it? Perhaps have gone for a more 'monolithic' approach?

<comment><AUTHOR> Yes, in hindsight I would have done more of a monolith datastore with fewer services. Faraday for auth was amazing - we could put anything we wanted behind it and centralize authentication/authorization. I liked how configurable Kubernetes was for everything from secrets to environments . Managing service discovery errors was annoying. Monorepo was a big win - <USER2> would always do this in the future.

</comment></comment><comment><USER6> To what extent did you try to refactor your Python code/architecture prior to adopting Go for v2? Also, could you share one example of the dynamic typing related problems? Specific metrics would be helpful to understand v1 limitations. Thanks for considering my question!

<comment><AUTHOR> I talked about this a little bit more on reddit [1] - basically, running Python code provided a lot of challenges.

We did a lot of design research prior to starting the V2, and we realized that we needed to make huge changes in our data normalization. For instance, in the V1 - we assumed that workers could only have one "role", but we realized that people can rotate between many jobs often. Making this change to the API while maintaining support for existing users would have been really difficult.

So, we basically started looking at all of the work we would need to do for a data normalization change, and said "well wait - if we were to build it from scratch, how long would that take?" That conversation also made us realize that we could jettison a lot of unneeded features if we started a V2.

We chose Go to address some of the issues that we had with Python, including ease of deployment, ease of running and lack of static typing.

[1] [https://www.reddit.com/r/Python/comments/5w3o6t/staffjoy_v1_...](https://www.reddit.com/r/Python/comments/5w3o6t/staffjoy_v1_has_been_open_sourced_if_you_want_to/de96ybk/?context=3&utm_content=context&utm_medium=user&utm_source=reddit&utm_name=frontpage)

</comment></comment><comment><USER7> Real-world software can be messy because sometimes you just have to get stuff done within time constraints.

<comment><AUTHOR> Yes. Protocol buffers and grpc-gateway made it easy to scaffold out a quick api, write all the interior logic, and know that there would not be any major issues due to strong typing. We used Gogoproto to annotate the protobuf files so that database crud is easy too.

</comment></comment><comment><USER8> Having worked with flask+Python eco-system and golang do you think if you continued with Python for v2 it might have been better (since you were already familiar with Python even though golang is statically typed)?

Also do you think Python 3.6 static checking with mypy would have eliminated need for go?

Another question is for algorithmic scheduling why you didn't use Python libraries but Julia, given your v1 was written in Python?

<comment><AUTHOR> No, I was having issues with too much "magic" in Python libraries. I'm continuing to use Go for my new company.

In particular, running SQLAlchemy was a nightmare (see a reddit comment I made about it here [1]). I also wanted a more parallel language - I was tired of having to use queues to do parallel tasks. Go's static typing made everything easier, from auto-generating Swagger definitions to having usable code documentation via Godoc. Most of our runtime errors while using Python were due to type mismatches that could have been caught by a compiler.

I'm unfamiliar with Python 3.6 static checking. I'll have to look into it.

For the algorithmic scheduling - our algorithms in Julia predate the existence of a web app. We had customers using the Julia-based algorithm using the protocol "spreadsheets over email". The website came later, and we ended up switching the algorithms from Julia to Python after the web-app launch [2].

[1] [https://www.reddit.com/r/Python/comments/5w3o6t/staffjoy_v1_...](https://www.reddit.com/r/Python/comments/5w3o6t/staffjoy_v1_has_been_open_sourced_if_you_want_to/de96ybk/?context=3)

[2] [https://blog.staffjoy.com/retro-on-the-julia-programming- lan...](https://blog.staffjoy.com/retro-on-the-julia-programming- language-7655121ea341)

<comment><USER8> Thanks for the reply and insight.

Why you had issues with magic in Python libraries, as I understand one of the main design goals of Python and its libraries is "Explicit is better then implicit" PEP-20 [1].

Indeed for our own project we chose python instead of ruby and ruby on rails just because of this PEP-20[1].

Your blog and moving to go alarmed us if there is anything wrong with python eco-system.

We tried go and due to too much boilerplate code and quality of the libraries we dropped it and when it comes to interacting with database especially postgreSQL all the speed advantage of go is not very useful as most tasks were IO intensive. Also the database driver in golang for postgresql is not as mature as psycopg. For CPU intensive tasks we relied on scientific python which is written in C and it worked well with multiprocessing and asyncio in python.

Also for the specific error you encountered in race conditions on update with multiple request. We solved it by using SQLAlchemy with_for_update()[2] which actually takes care at database level to make sure transactions are properly handled. As database we were using is postgreSQL, we wanted the database to handle ACID compliance, not implement in application code.

[1][https://www.python.org/dev/peps/pep-0020/](https://www.python.org/dev/peps/pep-0020/)

[2][http://docs.sqlalchemy.org/en/latest/core/selectable.html#sq...](http://docs.sqlalchemy.org/en/latest/core/selectable.html#sqlalchemy.sql.expression.Select.with_for_update)

</comment></comment></comment><comment><USER9> Interesting to see how other companies' application stacks end up looking. Thanks for releasing this.

<comment><USER10> Their React app definitely has a lot that could be done better. It is nice seeing what other people come up with in big orgs and learning from what they have written. Sometimes I have imposter syndrome to the max but this sort of codebase I can actually read

<comment><USER11> Their Go services definitely read like a very beginner or prototype project. There are no tests, lots of global state, and little separation of concerns between request/response business logic etc.

<comment><AUTHOR> Yes, it was a rush job. It started off nice, with tests and stuff. Then, we had to hit a deadline. I wrote 100% of the backend code. There were no other authors. Getting tons of functionality written without time to go back and refactor or improve as I improved my knowledge sucked, plus there were a lot of other non-code responsibilities at the time. If I had time, I would have spent a lot more time improving this code. For instance, I discovered gRPC interceptors way too late :-)

I recently started contributing to Buffalo, the Go web library by Mark Bates, and it addresses a lot of the issues we had, such as managing webpack for development environments.

Fun fact: I wrote a quick scraper in Go to relearn it before jumping in to the V2, and Francesc from Google did a code review of it for the first "Just For Func" episode. That made me realize just how much I had to improve my Go code: [https://www.youtube.com/watch?v=eIWFnNz8mF4&t=2s](https://www.youtube.com/watch?v=eIWFnNz8mF4&t=2s)

<comment><AUTHOR> > I really enjoyed that episode :)

> Curious, since it was just you writing the backend, what was the reasoning > behind doing microservices + react SPA. Both of those require a lot of > commitment, and coordination. Microservices especially are something I'd be > more likely to consider with a very large team/many teams instead of a > single developer.

> Would you choose a microservice architecture again?

For microservices - we were planning integrations with messy systems. Think, having to poll an API, deal with XML, or have to do custom auth on lots of different incoming data endpoints. Microservices made it easy to add new experiments (like our ical service) easily without adding complicated logic to the central datastore. For reference, we already had API keys and signed agreements with four integration partners (POS, HR, etc) that we wanted to roll out in a short period, with more people lining up. We also wanted to add messaging capabilities beyond SMS quickly, so that's why we architected the bot like that - where some providers had strict sending limits (like twilio) but others did not require as much of a strict queue.

For react - I didn't pick that and I've actually completely unfamiliar with the library. I'm learning VueJS now and that would be my choice for future SPAs. Now that I understand how shared components work, I would have changed a lot of the system design.

I'm already starting on my next company. It's a monorepo with three folders: pkg (packages), cmd (any `package main` commands), and static (all JS, SCSS, etc that gets built by Webpack then wrapped up in a single bindata.go). The primary app is a monolith. However, I'm making it possible to add additional service, such as cron jobs in separate containers or a command line utility based on the same protobuf definition.

<comment><USER11> Thanks for being so transparent and sharing your learnings! Good luck with your future project.

</comment></comment></comment></comment></comment></comment><comment><USER12> Hi Philip, does your app build really take 20 minutes?

<comment><AUTHOR> The Bazel build system [1] is the open-source version of Google's internal build system. It's tough to set up, but once you do - it caches all builds, down to the docker container generation. On changes, it analyzes affected upstream projects and selectively rebuilds them. So, after an initial build, rebuilds are blazingly fast. In fact, the simple act of creating a pull request means that most production builds/deploys come straight from cache.

Here [2] is a screenshot of the actual "master branch test, lint, build, and deploy 15 containers to kubernetes" job from our Jenkins. It took about 10 minutes on the build box every time.

That being said, in order to make builds work with Bazel, we had to do some wonky stuff. We committed built Javascript files, and we had to manually commit a lot of other types of data files (like bindata.go and protobuf outputs).

[1] [http://bazel.build](http://bazel.build)

[2] <I'll drop this in as soon as Imgur/S3 is back online . . . >

<comment><AUTHOR> [2] [https://i.imgur.com/cpeld6C.png](https://i.imgur.com/cpeld6C.png)</comment></comment></comment>


RTL-SDR compatible decoder application for the Meteor M2 weather satellite - <AUTHOR> https://www.rtl-sdr.com/a-complete-linux-based-receiver-and-decoder-application-for-meteor-m2/ <comment><USER2> I've got and RTL-SDR and love these little tricks. I showed a bunch of friends how it can decode transpoder (ADS-B) transmissions to track aircraft. "I can do that on my phone with flightaware." If I show them this they will say "My phone has a weather app". The magic of a tiny device receiving transmissions from aircraft and satellites is lost on most people. This is Trek-level technology. And it is a Russian satellite! Bond didn't have toys like this.

<comment><USER3> Look carefully, especially if you live near an Alpha or Beta level global city NYC, LA, SF, Chicago, DC, Miami in the United States. FlightAware took out the wealthy's private planes from their database at their request. There's lodes of exceptions to tracking if you are monied.

What we need is more people running things like RTL-SDRs to acquire data the rich and powerful want hidden to avoid exposure for shady activities.

[https://www.propublica.org/article/off-the-radar-private- pla...](https://www.propublica.org/article/off-the-radar-private-planes- hidden-from-public-view-040810)

<comment><USER4> Relevant discussion about blocked aircrafts on flightradar24 three years ago:

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

</comment></comment></comment><comment><USER5> This satellite is apparently passing over the UK in just 20 minutes! You can track it here: [https://www.n2yo.com/?s=40069&live=1](https://www.n2yo.com/?s=40069&live=1)

I hope this thing compiles quickly :)

EDIT: It needs a newer version of GTK than is available in apt for Ubuntu 16.04 LTS, this isn't going to happen for me tonight unfortunately :(

</comment><comment><USER6> Does this require a special antenna besides the SDR dongle?

<comment><USER7> To get a good result, yes. Here's an example that would be very easy to build with some coat hangers and a little coax - [https://www.rtl-sdr.com/simple- noaameteor-weather-satellite-...](https://www.rtl-sdr.com/simple-noaameteor- weather-satellite-antenna-137-mhz-v-dipole/)

That said, if it's flying overhead you could probably pick _something_ up with a basic telescoping antenna.

</comment></comment><comment><USER8> Edit: The issue I had was temporary, it seems to be working now.

</comment><comment><USER9> Very cool. Just this morning I was looking for a FIS-B decoder.</comment>


Covid-19 Has Affected Freelancing: A Global Survey of 1,365 Freelancers - <AUTHOR> https://www.hellobonsai.com/covid-19-study <comment><USER2> Yeah well. The "gig economy" proved to be an easy sell when everything was on the rise and booming. Not so nice for the individual 'giggers' when shit hits the fan. Not the ultra privileged taking the hit though. As usual. .. though I think the freelancers should've known and taking into account the risk of it though.

<comment><AUTHOR> Unpopular opinion but I feel freelancing's still safer than a full time job in the current scenario. You can charge higher & cushion yourself for an uncertain time (when it comes). Another great thing that you learn while freelancing is how to sell yourself.

It varies from industry to industry though. My opinion comes from being in tech. Could be different for events related industries - videography, photography, event planners etc.</comment></comment>


Ask HN: Would you pay to play? - <AUTHOR>

I am trying to figure out a pricing model for my application and I am left stuck wondering if I am doomed for failure because I force people to pay (at least $1) to play. The incentive is that you could win $100, so to me it kind of makes sense, but I know there are some people who still will find a reason to stop from throwing a buck up.
I was thinking I could potentially do a free system that allowed you to play and if you won, you would get N credits to use towards a paid puzzle (with a cash prize). It sounds like that may be better, but complicates my design.
So the quick question is this - Would you pay $1 for the chance to win $100 or would you put the work in to get free credits to potentially win $100? <comment><USER2> From your description it sounds like you'd be considered an online gambling operator by the SAFE Port Act in the US.

<comment><AUTHOR> Someone had mentioned this when I pitched the idea. Couldn't the fees to play be considered a service? You are not betting, but instead solving a problem.

<comment><USER3> You really need to seek some professional legal advice on this - you are thinking of setting up a gambling website, and will need to be registered with and regulated by the relevant authority.

If you are pitching this as a "service", I believe you will need to offer free play. An example from the UK: Let's say a particular chocolate bar brand is running a competition where you can win a prize by finding a special code inside the chocolate wrapper. They are legally required to offer free entry for this to be classified as a competition (so you can write to them and ask for a free entry form - they have to comply).

If you can only enter the "competition" by paying, it is considered gambling and regulated accordingly.

</comment></comment></comment><comment><USER4> I'm not a gambling person. In such cases there is one thing I know for sure: You won't throw away your personal money, so for every $ I win you will need to earn one $ (at least).

Another problem: How do I know, that your program is anything like playing fair? You could set up chances in program from anything like 1/100, 1/100,000 or no win at all. How do you want to built up a really great reputation for your customers to trust you on this?

The puzzle would even complicate matters. It would need to generate a new problem for every customer, otherwise you'll soon find the solution on the web and everybody will win. Or people will write bots to cheat about it.

<comment><AUTHOR> You have pointed out a few things I have been working with already. The first one I have covered, but that goes a lot more into the design.

To your second point, I am not sure. I obviously am not in the business to cheat people of their money, but I knew that could be a barrier initially. Any suggestions on building that trust? I believe I could be transparent with how the game is built without opening methods to cheat, but I would need to be sure and even then I think some would be skeptical.

The game itself is a shared real-time experience, so this would not be an issue.</comment></comment>


Hyperspace Is Shutting Down - <AUTHOR> There's no URL, but this arrived via email (hyperspace.app):
" HyperSpace is shutting down.
In 24 hours, HyperSpace will be taken offline and you will no longer be able to login nor access the information on Hyperspace.app. It's been five years since we began this journey. Five years pushing toward our vision, overcoming hurdle after hurdle, each unfamiliar, each unique and unexplored. Hurdles new to ourselves and to the market in which we were operating. In which we were pioneers.
... [ content removed here to fit Hacker News' 2,000 character limit ] ...
We kept pace with increasing regulation and relied on technology not-yet-ready for primetime, navigating the new waters on tight budgets throughout the long period of our existence. However, in 2019, the operational and regulatory burdens have become a prohibitive factor. We launched HyperSpace while facing increasing resistance from banks, regulators, and strategic content partners pulling out at the last minute after a great many resources were put into the efforts. We appreciate all of our followers who have supported us morally, financially, spiritually, and in so many other ways throughout the years. Your support allowed us to make a strong case for a truly disintermediated content economy. For a network fully operated and owned by its users. It allowed our collective voice to be heard, and our shared vision of freedom and fairness based on a new way to do Internet to permeate the world. Even without Synereo or HyperSpace, that voice lives on.
Our hearts go out to the tight community of creators that calls HyperSpace home. We sincerely hope you find a new, better one.
We have always appreciated your attention,
-- The Synereo Team" <comment><USER2> > "HyperSpace Pays its Users to Find and Share the Best Content on the Web."

From the "Well... that was that..." post: [0]

> "...shame all of a sudden they've run out of money."

That's an idea that will give you a negative bank balance from the start and is also chronically unprofitable.

No wonder.

[0] - [https://hyperspace.app/post/5db98d36329df6001049cee5](https://hyperspace.app/post/5db98d36329df6001049cee5)

<comment><AUTHOR> the problem is, I don't think the users can actually cash out. Those "amp"s are pure digital at this point. Maybe some thought that in the future they could cash out, but unless I'm missing something, there's no actual liquid money being given to the users</comment></comment>


Build Tools – Make, no more - <AUTHOR> http://hadihariri.com/2014/04/21/build-make-no-more/ <comment><USER3> I find these posts somewhat amusing. We've got people who (rightfully) question the tools they use and look for alternatives. They then discover Make and have some kind of zen Unix moment that they want to share with the world.

If what you are doing in your flavor-of-the-month build tool translates to a roughly equivalent number of lines in Make, then yes, you should probably look at using Make. But the thing is, Make is stupid, it doesn't know a lot. Sometimes that is a good thing, sometimes it is not.

I've written about this before on HN: I mostly program in C++ and when I build my stuff I want a build tool that understands things like header dependencies, optimization levels, shared libraries etc. It's a bonus if my build files are portable.

My point is that these alternative tools often strive to raise the abstraction level and the reason people use them isn't necessarily because they haven't discovered Make.

<comment><USER4> I find them irritating for the same reason.

It reminds me of the jQuery cycle: use jQuery for everything -> decide that depending on frameworks is lame -> use "vanilla JS" for everything -> realize this requires polyfills and various other inconvenient, inelegant things -> either go back to using jQuery, or gain a much deeper understanding as to why everyone uses it.

<comment><USER5> I doubt the analogy is apt.

Make is not an amazing (abit slightly bloated) meta tool that solves all your problems on all platforms (abit slowly).

Make _is_ vanilla javascript, along with all the bumps and hassles of not working correctly on multiple platforms, having odd obscure syntactic oddities and only kind of supporting various operations in newer versions (which may or may not be available on various platforms).

The newer build tools are trying to do _exactly what jquery does_ , and abstracting away those rough edges for a consistent build behavior with better syntax.

Going back to make is the 'use "vanilla JS" for everything' step in your list above, not the final step.

<comment><USER6> That was exactly the analogy the gp was making...

Make -> VanillaJS

Grunt/Rake/whatever -> jQuery

<comment><USER7> Taking the analogy a bit further, a vanilla proponent might put Make in the second category as well. Funny that modern web development requires a build process to change a line of CSS.

</comment></comment></comment></comment></comment><comment><USER8> Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well.

In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing will be recompiled/relinked if a constant in a header file changes for example! Changed function signatures will give you cryptic linker errors with the standard solution "just try make clean first".

To solve this you can either manually update the make file every time _any_ file changes the files it includes, which almost defeats the purpose of having an automatic build system. Or you can use automatic dependency generation by invoking your compiler with a special flag (-MMD for GCC), and suddenly make isn't as simple anymore as you laid it out to be. In conclusion your build tool must be aware of ALL inclusion rules as your compiler(preprocessor) has, or be given the information somehow. Maybe it's better to just use something designed for your particular toolchain that can come bundled with this knowledge?

<comment><USER9> Right. Make is mostly a kludge around the nonexistent module system in C and C++.

It's so bad (specifically due to the way file preprocessing works), that you need to have large parts of a compiler to accurately determine what the dependencies of a source file are.

This is why a decent module system should be the top priority for C++17, though it doesn't look likely so far.

<comment><USER10> Have you seen what Clang is doing[1]?

[1] [http://clang.llvm.org/docs/Modules.html](http://clang.llvm.org/docs/Modules.html)

</comment></comment></comment><comment><USER11> 1\. Since make has builtin suffix rules, the Makefile could be simplified to:

        CXX=g++

        hello: main.o factorial.o hello.o

        clean:
            rm -rf *o hello

2\. Shameless plug: he didn't mention redo [1], which is simpler than make and more reliable. The comparable redo scripts to the Makefile would be:

        cat <<EOF > @all.do
        redo hello
        EOF

        cat <<EOF > hello.do
        o='main.o factorial.o hello.o'
        redo-ifchange $o
        g++ $o -o $3
        EOF

        cat <<EOF > default.o.do
        redo-ifchange $2.cpp
        g++ -c $1 -o $3
        EOF

        cat <<EOF > @clean.do
        rm -rf *o hello
        EOF

[Edit: Note that these are heredoc examples showing how to create the do scripts.]

These are just shell scripts and can be extended as much as necesary. For instance, one can create a dependency on the compiler flags with these changes:

        cat <<EOF | install -m 0755 /dev/stdin cc
        #!/bin/sh
        g++ -c "\$@"
        EOF

        # sed -i 's/^\(redo-ifchange.\+\)/\1 cc/' *.do
        # sed -i 's}g++ -c}./cc}' *.do

sed calls could be combined; separated here for readablility.

[1] [https://github.com/gyepisam/redux](https://github.com/gyepisam/redux)

<comment><USER12> redo might be simpler and more reliable, but shell isn't. And redo is encouraging even more work to be done in shell. Additionally, the redo version is more verbose and harder to read. While fancier tasks will make's version look horrible relatively quickly, they won't make redo's version look any better.

<comment><USER13> To this day I still don't understand redo (I'm just staring at it, and don't get anything) - haven't really read the internals.

With make it was easier for me to grasp the idea (or maybe I was simply 20 years younger then).

<comment><USER14> I think the big difference between redo and make is that make requires knowledge of dependencies up front, and this is sometimes tricky to get right.

"as you can see in default.o.do, you can declare a dependency _after_ building the program. In C, you get your best dependency information by trying to actually build, since that's how you find out which headers you need. redo is based on the following simple insight: you don't actually care what the dependencies are before you build the target; if the target doesn't exist, you obviously need to build it. Then, the build script itself can provide the dependency information however it wants; unlike in make, you don't need a special dependency syntax at all. You can even declare some of your dependencies after building, which makes C-style autodependencies much simpler."

[https://github.com/apenwarr/redo](https://github.com/apenwarr/redo)

</comment></comment></comment></comment><comment><USER15> A build DSL solves the problem of making your build rules and systems _first- class citizens_. It's not just learning a new syntax—in fact, since you're embedding into a known language, it isn't even that new—it's about getting more control. You can pass rules around, modify them and do whatever arbitrarily complex tasks you need in a natural, straightforward way using your favorite programming language. You don't have to contort yourself and bend over backwards to fit the logic you want into Make's limited and peculiar language.

Your build system is an integral part of your whole program and you want to treat it just like any other code. This means refactoring, this means modularity, this means libraries, this means no copying and pasting... All this is far easier with a system embedded in your main language than in Make. You can use your existing tooling, debuggers and frameworks to support your build system. If you're using a typed language, you can use the types to both constrain and guide your build files, making everything safer.

Using an embedded DSL integrates far better with the rest of your ecosystem than relying on Make.

Apart from making the logic _of_ your build system easier to describe and maintain, an embedded DSL also makes arbitrary meta-tasks easier. You might want to monitor random parts of your build process, report to different services, connect to different front-ends (an IRC bot, a CI system...) and maybe even intelligently plug into the features of your main language. Wouldn't it be great to have a make system that's deeply aware of how your server is configured, how your type system works, what your compile-time metaprogramming is doing an so on?

You could just glue together a bunch of disparate scripts with a Make file. Or you could use a DSL and call these services through well-defined, maybe even _typed_ interfaces! No need for serializing and deserializing: you can keep everything inside your system.

Sure, if you're just going to use your DSL as a different syntax for Make, you're not gaining much. But it allows you to do far more in a far better way, while fitting in more naturally with the rest of your code. I'm definitely all for it!

<comment><USER16> Can you show an example of what you are describing? It doesn't sound interesting for the tasks I have in mind, so it must be the case that you are dealing with very complex tasks.

<comment><USER17> See ASDF, for example ([http://common-lisp.net/project/asdf/](http://common- lisp.net/project/asdf/)).

</comment></comment></comment><comment><USER18> I think everyone goes through a phase where they try to find the perfect build tool, and then at least entertain the idea of writing one themselves.

Eventually, you grow out of it. There's a lot of build tools, each are better at some things than others. It's not that much grunt work to convert things from one to another (even very large projects). If your build tool is working for you, leave it alone. If it's getting in your way or slowing things down, try another one. Move on.

</comment><comment><USER19> I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell.

For example:

        clean:
             rm -rf *o hello

Did you really mean to erase all files and directories that end in "o"? Let's say it's just a typo and fix it: "*.o".

Now, are you sure it'll handle files with spaces in the name? What about dashes, brackets and asterisks? Accents? What if a directory ends in .o? Hidden files?

This specific case may support all of the above. But if it doesn't, what will happen? How long until you notice, and how long still to diagnose the problem?

Just like I prefer static strong typing when developing non-trivial projects, the build system should be more structured. I agree endless reinventing is tiring, but it may have some credit in this case.

<comment><USER20> I'd expect all developers using make to know about this and never have this problem thanks to one simple thing: sticking with sensible names (no spaces, no brackets, no stars and other special characters in the name - <USER2> underscores!).

It's an easy rule.

        Just like I prefer static strong typing...

You probably don't use any special chars or spaces for identifiers in whatever the language you're programming in. This is just applying a similar rule to the files of your project.

<comment><USER19> For source code files I agree completely; but the build system will encounter other types of files that aren't so strict.

Maybe you downloaded something and it came with a bracket because that was in the page title. Or you copied a duplicated file and your system helpfully appended " (2)" at the end. Or there was an excel file updated by someone not so technical and this person didn't know they have to strip accents from the words in their native language (possibly losing meaning). Or someone saved their "Untitled Document.txt". Or you needed to include a date in the directory name. Or you are just human and didn't mean to break the build by pressing the biggest button on your keyboard when saving a file.

And remember "break the build" here is not "a red light flashes and you get an email". It means you get unknown behavior throughout the process, including security features and file removal.

Strict rules for source code file names are good because names usually bleed into the language itself. Python file names __become __identifiers when you import them. Identifiers in turn are strict because parsing is strict, and there are many good reasons for strict parsing in general purpose languages.

Lacking accent support in file names, as some very popular software do, is terrible. Lacking support for spaces is just atrocious.

I love shell, I use it daily for one-off tasks, but I don't think it's a good fit to manage the build system of a project.

</comment></comment></comment><comment><USER21> For me, the only justification for using a language-specific build tool (e.g. grunt, rake, paver, ...) is when you actually want to exchange data with a library / program written in that language. On the other hand, you could probably accomplish the same effect using environment variables, with the upside of having a cleaner interface.

For those that are curious which build tools exist for Python, here's an (incomplete) list:

* pyinvoke ([https://github.com/pyinvoke](https://github.com/pyinvoke)) - claims to be the successor of fabric, pretty solid and well-maintained

* fabric ([http://www.fabfile.org/](http://www.fabfile.org/)) - not actually a build tool but often used as one

* paver ([http://paver.github.io/paver/](http://paver.github.io/paver/)) - no longer actively maintained

* doit ([http://pydoit.org/](http://pydoit.org/)) - one of the few tools that actually support monitoring file states (like the original make)

* disttools ([https://docs.python.org/2/distutils/](https://docs.python.org/2/distutils/)) - not actually a "universal" build tool but intended to distribute Python packages

<comment><USER22> You forgot buildout[1], which is probably more than a build system, perhaps putting a toe into the configuration management world.

1\. [http://www.buildout.org/](http://www.buildout.org/)

Documentation can be challenging to find, and it isn't the most actively developed project in the world, but what it does, it does pretty well (including supporting more than python dependencies).

<comment><USER21> Thanks for posting the link! I hesitated including configuration management tools since the use case is not the same. There's a lot of interesting stuff going on there though: With Saltstack and Ansible we have two serious "chef" contenders for Python now.

</comment></comment></comment><comment><USER23> the last 10 years in build tools has felt like 1 step forward, two steps back. i like being able to write tasks in any language other than Makefile. however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. new task runners have either eliminated or pigeonholed the (typically one-to-one in makeland) correspondence between tasks and files, meaning the build system can't be intelligent about what tasks to run and which to not.

computers are fast enough that this doesn't often bother me anymore, but i've run across some huge Rakefiles that could benefit from a rewrite in Make.

<comment><USER24> > however, it seems like many of the new popular options (cake, grunt, etc.) > don't do what, to me, is Make's real purpose: resolve dependencies and only > rebuild what's necessary.

You might like tup[1]. Its killer feature is that it automatically determines file-based dependencies by tracking reads and writes (using a FUSE filesystem). It has an extreme emphasis on correct, repeatable builds, and is very fast. Other stuff:

\- does work in parallel, and will let you know if your build isn't parallel safe. (note it is NOT relying on your specification of dependencies: even if you manually specify dependencies, it will tell you if something's wrong based on what it actually observes your dependencies to be)

\- tracks changes to the build script and reruns if the commands change.

\- cleans up old output files automatically if build rules are removed.

\- lets you maintain multiple build variants (say for different architectures, configurations, etc)

\- autogenerates .gitignore files for your build output

\- very easy to get started, and "Just Works".

\- for advanced usage, it is scriptable in Lua.

I've tried every build system out there. For Unix-y file-based build tasks, tup is, by far, the best. I don't know why it isn't more well known.

[1]: [http://gittup.org/tup/index.html](http://gittup.org/tup/index.html)

<comment><USER25> I was already sold on tup after reading the first paragraph comparing it to make[1]:

"This page compares make to tup. This page is a little biased because tup is so fast. How fast? This one time a beam of light was flying through the vacuum of space at the speed of light and then tup went by and was like "Yo beam of light, you need a lift?" cuz tup was going so fast it thought the beam of light had a flat tire and was stuck. True story. Anyway, feel free to run your own comparisons if you don't believe me and my (true) story."

[1]: [http://gittup.org/tup/make_vs_tup.html](http://gittup.org/tup/make_vs_tup.html)

<comment><USER26> My favorite is the "Tup vs Mordor" benchmark.

</comment></comment></comment></comment><comment><USER27> Another vote for higher-level meta-build-systems like cmake, premake or scons (I'm using cmake because it has very simple cross-compilation support). My personal road to build-system nirwana looked like this, I'm sure this is fairly common:

\- Started using hand-written Makefiles and autoconf. Then someone wants to build on Windows, in Visual Studio nonetheless. Add manually created VStudio project files to the project. Then someone wants to use Xcode, so add manually created Xcode project files. Now you add files, or even need to change a compiler option. Fix the options in the Makefile, open the VisualStudio project, fix the options there, open the project in Xcode, fix the options there. Depending on the project complexity, this can take hours. The next guy needs to build the project in an older VisualStudio version, but the project files are not backward compatible...

\- Next step was to create my own "meta-build-system" in TCL (this was around 1999), which takes a simple descriptions of the project (what files to compile into what targets, and the dependencies between target), and creates Makefiles, VStudio-files and Xcode-files, this worked fine until the target project file formats change (happens with every new VisualStudio version).

\- Someone then pointed me to cmake which does exactly that but much better (creates Makefiles, VStudio-, Xcode-projects, etc... from a generic description of the sources, targets and their dependencies), and I'm a fairly happy cmake user since then.

\- Recently I started to wrap different cmake configuration (combinations of target platforms, build tools/IDE to use, and compile config (Release, Debug, etc...)) under a single python frontend script, since there can be dozens of those cmake configs for one project (target platforms: iOS, Android, OSX, Linux, Windows, emscripten, Google Native Client; build tools: make, ninja, Xcode, VStudio, Eclipse; compile configs: Debug, Release). But the frontend python script only calls cmake with the right options, nothing complicated.

Of course now I'm sorta locked-in to cmake, and setting up a cmake-based build-system can be complex and challenging as well, but the result is an easy to maintain cross-platform build system which also supports IDEs.

I general I'm having a lot less problems compiling cmake-based projects on my OSX and Windows machines then autoconf+Makefile-based projects.

[edit: formatting]

<comment><USER28> I agree with this. As a cross platform (ie, Windows + OSX + Linux) person who enjoys Visual Studio (XCode less so) I need more than make.

My own experience is with gyp and ninja which is used by the Chromium team ([http://martine.github.io/ninja/](http://martine.github.io/ninja/)) which they use to build Windows, OSX, Linux, Android (and maybe iOS?)

Of course for personal projects I'll probably never notice the speed difference but for bigger ones Ninja is FAST.

<comment><USER29> CMake outputs to Ninja as well. It's the only way I know how to use Ninja in fact.

</comment></comment></comment><comment><USER30> I've recently been playing with ninja, which does a good job of not being 'just another make' [http://martine.github.io/ninja/](http://martine.github.io/ninja/). To quote their website, "Where other build systems are high-level languages Ninja aims to be an assembler.". It's used as a backend for GYP (Google Chromium) and is supported by CMake as well. I've had good success generating the files manually using something like ninja_syntax.py: [https://github.com/martine/ninja/blob/master/misc/ninja_synt...](https://github.com/martine/ninja/blob/master/misc/ninja_syntax.py).

I also note that google are working on a successor to GYP, GN which targets Ninja [http://code.google.com/p/chromium/wiki/gn](http://code.google.com/p/chromium/wiki/gn).

<comment><USER31> Thanks for the plug! In line with the original post, I'll add that the Ninja manual has a section where we try to convince you to _not_ use Ninja and instead use a more common build system: [http://martine.github.io/ninja/manual.html#_using_ninja_for_...](http://martine.github.io/ninja/manual.html#_using_ninja_for_your_project)

</comment></comment><comment><USER32> I'm 52 years old. I've had this discussion with dmr, srk, maybe with wnj.

All I know is for years, decades, I carried around the source to some simplistic make. I hate GNU make, I hate some of the unix makes. I loved the simple make.

The beauty of make is it just spelled out what you needed to do. Every darn time make tried to get clever it just made it worse. It seemed like it would be better and then it was not.

Make is the ultimate less is more. Just use it and be happy.

</comment><comment><USER33> Dunno if the owner of the site will read this, but here's a tip. Don't show a full screen overlay telling me how my visit would be better with cookies enabled.

1) I have cookies enabled. 2) The Eurpoean law is daft, but since you feel you must comply do it in a more user friendly way.

<comment><USER34> I know. I don't agree with it much either and I found this least intrusive (wasn't aware of issue on mobile). If I can find a better solution, will change.

Thanks.

<comment><USER35> In what way would my reading that blog post have been a better experience for me with your tracking cookies?

</comment></comment></comment><comment><USER36> Nothing against make, but I've found that it feels really nice when the majority of your toolset uses the same language. This is what I liked about Rails. Rails is ruby. Bundler is ruby. Rake is ruby. It's all ruby, which allows for a certain synergy, streamlined feel, and less cognitive overhead. I don't blame the js folks for attempting something similar.

<comment><USER37> Agreed. Mixing languages is fine when necessary, but a single language is usually preferable to me. My dev team has been using Grunt in projects thus far and have been pleased with Gulp in small experiments.

</comment></comment><comment><USER38> Misses the fundamental point that Make is broken for so many things. To begin with you have to have a single target for each file produced. Generating all the targets to get around this is a nightmare that results in unreadable debug messages and horribly unpredictable call paths.

nix tried to solve much of this, but I agree it can't compete with the bazillion other options.

<comment><USER39> It does not miss it, just ignores it. The author states that there are lots of things we can improve but the point is that we have too many variations on the theme without converging to a solution that has few (or no) dependencies and comes with built-in build knowledge and the ability to discover what you want rather than make you declare it.

Such a tool should be: \- Zero (or few) dependencies. Likely written in plain C (or C++, D, Rust) and compiled to distribute in binary form. \- Cross- platform \- Support any mix of project languages and build tasks. \- Recognizes standard folder hierarchies for popular projects. \- Easy enough to learn. Not overly verbose (looking at you, XML). Similar to Make if possible.

Examples of the auto-discovery: It can find "src", "inc", and "lib" directories then look inside and see .h files then make some educated guesses to build the dependency tree of header and source files (even with mix of C and C++). Or it could see a Rails app and figure out to invoke the right Rake commands, perhaps checking for the presence of an asset pipeline etc. Or a Node.js project. It could check for GIT or SVN and make sure any sub-modules have been checked out.

<comment><USER40> The dependencies thing is a killer. I remember a Windows developer co-worker insisting that _everyone_ had the .NET runtime installed, and after shipping it turned out that most of our customers _didn 't_ have it installed, to which he finally said, "well, _I_ always have it installed." (To be fair, I should have pressed him harder, and I did ask the question twice, but because I'd never built against the runtime I was unprepared for any challenge.)

Almost every new project I download starts with a sad, manual, and demoralizing installation of a bunch of third-party stuff that you have to google to find out what's missing. And it's not educational at all, because in a few years all these tools will now be obsolete.

(The best project I ever encountered was the Stripe CTF, which almost always used just one command to install a complete working copy of _everything_ you needed and didn't have. I'm still impressed with that.)

</comment></comment></comment><comment><USER41> I think the main problem with these articles is that the examples given are exceedingly simplistic, and hence in no way represent real world build systems. It's very easy to have a build system look nice and clean for trivial examples, when it breaks down is when the software it builds gets more complicated and the number of hacks and extra code is added making the build system into a big mess.

</comment><comment><USER42> I've been thinking a lot about build systems lately. I enjoy the discussion that this post has provoked. The post itself is weaker than it could have been, in that it does not stick to a single example when comparing build tools, and does not pin down any criteria for distinguishing between build tools.

If you are interested in a comparison of a few interesting build tools, please check out Neil Mitchell's "build system shootout" : [https://github.com/ndmitchell/build- shootout](https://github.com/ndmitchell/build-shootout) . Neil is the author of the `Shake` build system. The shootout compares `Make`, `Ninja`, `Shake`, `tup` and `fabricate`.

Another possibly interesting build tool is `buck`, although it is primarily aimed at java / android development. See [http://facebook.github.io/buck/](http://facebook.github.io/buck/) . There's a little discussion about `gerrit`'s move to `buck` here: [http://www.infoq.com/news/2013/10/gerrit- buck](http://www.infoq.com/news/2013/10/gerrit-buck) .

Here's some questions I'd ask of a build system:

\- is it mature?

\- which platforms does it support?

\- which language ecosystems does it support? (language-agnostic? C/C++? ruby? python? java?)

\- does it support parallel builds?

\- does it support incremental builds?

\- are incremental builds accurate?

\- is it primarily file-based?

\- how does it decide when build targets are up-to-date, if at all? (e.g. timestamps, md5 hash of content, notification from the operating system)

\- does it allow build scripts for different components to be defined across multiple files and handled during the same build?

\- does it enforce a particular structure upon your build scripts that makes them more maintainable?

\- how does it automatically discover dependencies, if at all? (e.g. parsing source files, asking the compiler, builds instrumented via FUSE/strace)

\- how easy is it to debug?

\- is it possible to extend in a full-featured programming language?

\- does it let you augment the build dependency graph mid-way through execution of a build?

\- how simply can it be used with other tools such as your chosen continuous integration server, test framework(s), build artifact caches, etc?

Many of these criteria are completely overkill for trivial build tasks, where you don't really need anything fancy.

</comment><comment><USER43> One big advantage of vanilla Make is the community. There are some very nice tools that work well with make (such as [https://github.com/mbostock/smash](https://github.com/mbostock/smash)).

<comment><USER44> I love documentation that has humor, as long as it doesn't get in the way.

What's special about the Make community as opposed to the Grunt or Gulp communities?

<comment><USER12> For that matter, what's special about the Grunt or Gulp communities?

</comment></comment></comment><comment><USER45> At least we are moving the direction of Grunt/Gulp rather than a maven sort of direction. Many lives lost to maven, somewhat of a Vietnam of build tools. You might think you are a Java developer with it but truly you are a maven servant.

</comment><comment><USER46> This post rather misses that while Make is simple, making Make do all the things we're used to (e.g. Java dependency management) not as simple.

I'd like to think people have decided that it's easier to replicate the task part of Makefiles onto their environment as the simpler alternative to making dependency management and various other language-specific tasks available to make.

</comment><comment><USER47> Never underestimate a young developer's need to reinvent reinventing the wheel.

</comment><comment><USER13> Make is the "assembly" language for build systems. Qt's qmake/cmake target it, and the output produced is horrible, but then using "make -j8" or qt's own "jom.exe -j8" as replacement for the underperforming nmake.exe and you are all set.

</comment><comment><USER48> Make is still the best build tool form me.

[https://algorithms.rdio.com/post/make/](https://algorithms.rdio.com/post/make/)

</comment><comment><USER49> I've never felt hindered by Gradle.

Hindered by the fact I can't add an arbitrary github repo through Gradle? Yes. That seems like it should be solvable though...

<comment><USER50> Add an arbitrary GitHub repo to what? In what capacity? You mean as a source dependency, an artefact repository, what?

</comment></comment><comment><USER51> Heh. The one and only time that I ever wrote a parser in my professional career was for a build tool. In my defence, at the time I didn't know much about command line tools, and had only really programmed in IDEs. So when the new project was to be compiled on the command line, I quickly discovered that maintaining dependencies, changing targets and doing all the other things that a build system generally does by hand quickly gets old. Not knowing that autotools, cmake, ant, and about a bajillion other tools already existed to do just this, I wrote my own language, with a parser in ruby, no less :D

I have since repented. I find autotools (with occasionally a script of [ruby|python|perl] to handle something that would otherwise be tricky to do in make or m4, which is then called by the makefile) works a treat. Just don't try to do anything tricky in the auto tool files - as I said, boot anything exotic out to a separate tool.

Also, any discussion of build tools without also discussing package management is but half a discussion.

</comment><comment><USER52> I'm unreasonably fond of Ant - there's plenty of scope for pointless clever- dickery, and there are days where that's all that keeps me going!

Nice to see it mentioned in a context other than "oh god what a mess"... even though, in fairness, many aspects of it are a complete dog's dinner.

<comment><USER53> Ant is a Turing-complete language in XML.

That is horrifying.

It is bloated, difficult to read, tends towards duplication. It also doesn't do dependency management all that well, doesn't cache build results (so it does a complete rebuild every time), and is difficult to extend.

Not an Ant fan. I have used both Rake and Gradle successfully, and have been much happier with each. Their scripts tend to be (much) more compact, easier to read, and less prone to duplication.

<comment><USER54> I agree with a lot of your points, but can you explain the part about it doing a complete rebuild every time? It doesn't do that for me (unless I specifically tell it to).

<comment><USER53> My apologies: I just wrote a basic HelloWorld.java and a build.xml to go with it, and it looks like it doesn't recompile the class unless there is a change to the source .java file. So I was mistaken about that.

Wonder what Gradle's caching, then?

<comment><USER55> > Wonder what Gradle's caching, then?

Let's hope it's catching another scripting language or two in its upcoming version 2 because having Groovy as the only option does it no favors.

</comment></comment></comment></comment></comment><comment><USER56> In fact I agree. I would be really glad if somebody explained me persuasively which one build-tools is the best one ever, so I could use it always and for everything, even when a shell-script would be enough. Yeah, it would be nice. But then, don't we have the same thing with about every class of software? Tens of text-editors and no perfect one. Many OSes and nothing sane. So many programming languages with overlapping functionality! And we won't even talk about such thing as linux distributions (and their packaging tools), pepsi&coca-cola… oh, it's not even software.

So, yeah, there are too many build-tools. Whatever.

</comment><comment><USER57> I hate how far spread apart the JS community is but I'm excited for the day it starts to all come together and we don't have to worry about Javascript stacks becoming outdated within 6 months

</comment><comment><USER58> I appreciate Grunt and Gulp, but still fall back to Make for many of my web projects, even those that require a CSS or Javascript build system.

Here's a Makefile example that utilizes fswatch: [http://blogs.mpr.org/developer/2014/02/makefile/](http://blogs.mpr.org/developer/2014/02/makefile/)

</comment><comment><USER59> I'm currently working on a build tool that doesn't work using the traditional "makefile" approach. Instead it's designed as a Python library, and you have the full power of Python at your disposal.

Sadly it's not ready for prime-time yet (early designing stage), so I won't link my highly unfinished project.

<comment><USER60> I suspect your downvotes are coming because you haven't mentioned [http://www.scons.org/](http://www.scons.org/). Letting you know in case you're not aware of it. (I would have emailed you out-of-band, but there's no contact info in your profile. Sorry for the noise, everyone else)

<comment><USER61> Scons uses Python more for configuration rather than the control flow. I'm sure most people think that's ok, but I find it limiting and a bit too derpy.

<comment><USER62> In fairness that's the core of the argument: a significant proportion of people that have had to maintain build tools over long periods believe they should only be configuration and not contain any control flow.

The problem with adding flow control is that establishing the dependencies without actually executing the whole process becomes next to impossible.

</comment></comment></comment></comment><comment><USER63> Rich Felker, the lead developer of musl libc, uses make to generate his ewontfix.com blog. See [http://ewontfix.com/Makefile](http://ewontfix.com/Makefile)

<comment><USER64> Pelican [1] uses make and python to generate a blog. Simple makefiles are great.

1: [http://blog.getpelican.com/](http://blog.getpelican.com/)

</comment></comment><comment><USER65> I get redirected with. "Your experience on this site will be enhanced by allowing cookies"

I need cookies to read a blog post? Don't think so. Probably not worth the read

<comment><USER34> No. You don't. But EU laws requires that if you use Cookies for things such as Google Analytics or even just stats, you must inform the user. And you can switch it off.

</comment></comment><comment><USER66> What about having your text editor do the build for you (use `.dir-locals.el` in emacs to compile your less on save for example)

</comment><comment><USER67> Why would you need Grunt just to compile LESS?

<comment><USER68> It is a non-ad-hoc specification of your build, and it allows you to integrate things like LiveReload more easily.

</comment></comment><comment><USER69> I start using [https://github.com/rags/pynt](https://github.com/rags/pynt), and what a change. Is the simples thing you can imagine. Combining with request and [http://plumbum.readthedocs.org/en/latest/](http://plumbum.readthedocs.org/en/latest/) (or similar) and whoila, you are done.

</comment><comment><USER70> What about contribution packages of Grunt/Gulp?

</comment><comment><USER71> So he's saying use 'make' instead of gulp/grunt and then he submits an example where it's as easy as piping through GCC.

He's making the wrong assumption that you don't need to setup a build environment when building with make, but to have gcc you will still also need to install g++ and build-tools. Also, he refers to building on Windows using yet another specialist tool, but have you recently tried building anything C++ on Windows when you don't have visual studio, or even worse, CYGWIN installed?

When you make such a statement, then please show me a makefile that's not 10.000 lines long, that will do the same as this, but without NPM and 'downloading half of the internet'.

       gulp.task('scripts', function() {
          // Minify and copy all JavaScript (except vendor scripts)
         return gulp.src(paths.scripts)
          .pipe(coffee())
          .pipe(uglify())
          .pipe(concat('all.min.js'))
          .pipe(gulp.dest('build/js'));
      });

I submit that's impossible, simply because this stuff took 2 years to evolve (for the Javascript toolchain, that is) and a lot of people went through hours of frustration trying out alternative methods.

<comment><USER72> > this stuff took 2 years to evolve and a lot of people went through hours of > frustration

GMake was first released in 1977: [http://en.wikipedia.org/wiki/Make_(software)](http://en.wikipedia.org/wiki/Make_\(software\))

They've worked on this thing for decades

There are 42,000 issues filed for make. if you could resolve each of these issues in 10 minutes, you'd spend 291 days of frustration. [http://savannah.gnu.org/bugs/?group=make](http://savannah.gnu.org/bugs/?group=make)

kids these days.

<comment><USER71> My point was referring to the JS toolchain here mostly. I get that for C, make is the tool for the job.

<comment><USER73> make is a general-purpose tool for describing dependencies for regenerating files. It would be worth your while to learn make, and try it on your example. Understand that it's a declarative language ("A depends on B"; when "B" changes, here's how to update "A"), and not a scripting tool. This is a good thing.

In my experience, make is coupled to Unix. Make is not coupled to C.

<comment><USER74> On one hand, _make_ typically comes with built-in rules for .c targets.

On the other hand, _make_ can't cleanly handle #include dependency detection. I doubt that there is any major C project where "make extraclean" (or its equivalent) isn't occasionally necessary.

So yeah it's really not very well suited for C.

<comment><USER75> What is wrong wrong with just using the following.

Given it would be nice if make had a builtin macro to do this, but it is not too bad to type out.

depend: .depend

.depend: ${SRC} ${CC} -MM -I. ${SRC} > .depend.X && mv .depend.X .depend

include .depend

Makefile: .depend

<comment><USER74> Because now _make_ can't build a clean source tree.

I believe _make_ parses the entire Makefile before running it.

<comment><USER75> GNU make restarts when a Makefile: dependency changes. So it works perfectly fine. Try it ...

<comment><USER74> What happens if you list _depend_ as a dependency of the first target?</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Coronavirus rest API and example front end, node - <AUTHOR> github: https://github.com/javieraviles/covidAPI
node and ionic app. deployed to heroku using actions.
frontend: https://coronavirus-19-api.herokuapp.com/
api rest: https://coronavirus-19-api.herokuapp.com/all and https://coronavirus-19-api.herokuapp.com/countries <comment><USER2> frontend is dead right now (1733 PDT)</comment>