This is chock full of platitudes and obfuscation. Pinboard appears to have participated in good faith, as you admitted yourself. It seems rather like HN/YC had never intended to allow Pinboard to win, even before any votes had been cast.
If your aim with this contest was to pilot something new and unique that might further distinguish YC, I suppose you've done just that, even if in the opposite direction. Sometimes karma is more than just a column in your database.
Parent is most likely referring to the telnet GOAHEAD character and its related SUPPRESS GOAHEAD protocol: https://tools.ietf.org/html/rfc858
I am the author of a MUD client for iOS[0] that, like most other clients, will capture and silently discard the GOAHEAD character. GOAHEAD is most common on MUSHes but I've seen them in a few MUDs as well.
A Facebook spokesman says the company “doesn’t have shadow
accounts or profiles – hidden or otherwise – for people
who haven’t signed up for our service,” and a 2011 audit
by Ireland’s Data Protection Commissioner confirmed this.
Does anyone really believe that Facebook is not assembling shadow profiles for as close to 100% of the human population as is possible?
Siphon as much data as possible. Keep it indefinitely, but don't synchronously add rows for shadow identities. Instead, build a querying infrastructure that projects your mountain of data into forms you can exploit at runtime. Part of this is sorting activity into unbound identities.
Now you get to have your cake and eat it too: all of the delicious privacy invasion, with the PR/legal bonus of being able to say you don't have "shadow profiles".
I'm sure Facebook has shadow profiles on everyone, just as I'm sure they're smart enough to prove they don't.
Exactly. Facebook doesn't have shadow profiles, they have user data and algorithms. The algorithms traverse the shadow profiles at runtime and produce some output, but there is no need to hold onto the profile data in that form. All facebook needs is the advertising "action-item" that the algorithm produces.
The same analysis applies to the intelligence gathering done by the government. They hold onto all data for all time and draw conclusions from it at a later date.
Whats to stop anyone from doing that now using "open graph"/crowd sourcing and geotagging from seo queries upon names and identities? C&D letters from facebook lawyers they will inevitably send your way from complaints of users asking how you're doing what your doing and to stop, and claim to be protecting users? Ha… I mean seriously with all the public data-sets out there associated with identities, do people really need things like users and login accounts for people to engage in the same behavior as they do on facebook? Are people naive enough to believe that they need to have such to engage in the same social behaviors in a similar fashion?
With 20 VM's located from unknown places in the world, you can mine everyone from FB and query data that facebook declares "public" in about two months… for about $200 total… wanna build a open sourced facial recog database with profile photos (graph.facebook.com/{your_user_id}/picture?type=large)[and then use crowd-soursing to make such better for images that don't get put into the model from not passing simple feature detection from open source recog libraries out there]. Want to query an ip address and return a probability distribution for names associated with pages visited with such + browser fingerprinting techniques written about in enough detail to bore anyone? Prob can't build a business on top of it from it within the US (maybe), but that's what legal arbitrage is for.
Things existed before facebook, things will exist after…
CI means knowing that your product is always in a releasable state. Green tests is only one small piece of that.
I have an iOS app or two that I work on independently, as side projects. Even though I am the sole developer on these projects, CI saves me dozens or hundreds of hours of time. My CI script[0] downloads provisioning profiles from Apple's Developer Center, installs them, runs my tests, builds my app, archives the resulting IPA and .dSYM.zip to Amazon S3, uploads the build to Testflight, notifies my testers, then sends my iOS devices a push notification with an ultimate success or failure message.
And it does all of this every day at 4am, while I'm sleeping, and I don't have to think about it.
How much longer would all of this take if I were doing it manually each time? Time is the only infinitely valuable scarce resource. I don't want to spend time mucking with codesigning and provisioning profiles; I want to spend more time coding.
If this is all happening at a set time every day, couldn't it just be a cron job? You do have the script created already, CI is just running it for you.
Sure it could be a cron job, but using Jenkins adds some conveniences: a nice UI to browse projects, plus it archives the output of every historical build, locally-archived build artifacts, lots of extensibility with plugins, and so on.
Plus: Once you already got everything up and running you can take it a step further and deploy from the CI Server. In my previous job, the Ops Team loved it when I told them how to deploy from the CI instead of going to the "Release Developer" (Which was loathed by the Ops, because she was not the friendliest person :D)
It's worth adding that it does those things based on the output of previous jobs. Also, if you have many of these setups in parallel, it can create good dashboards and give you one nice (and free) GUI to take in the state of your build empire.
On the one hand, the announcement is correct that "email is here to stay" and it's exciting to see innovation on top of an ancient protocol that was never intended for the abuse it receives today (IMAP).
On the other hand, the announcement is correct that "email is here to stay" and because my entire life runs out of my inbox, I am almost certain to never grant an arbitrary third party like Inbox access to my mail. How does Inbox make money? And Inbox fully intends to store my mail; why should I trust them?
On the other other hand, I have been a long-time happy customer of Fastmail.fm and I am both amused and disappointed to see that Inbox does not support an arbitrary IMAP connection (e.g. to support Fastmail).
Michael from Inbox here. First of all, we love Fastmail and think they're great. :)
We're working hard to support any IMAP server, and it's our goal to support all providers. We just started with Gmail/Yahoo because they were the two largest services and made testing easier. IMAP is a tricky protocol to get right, with many various extensions that are not always supported or enabled.
We know we need to work to gain the trust of developers, and show that this is a product and company built by developers for developers. It's one of the reasons we decided to make the sync engine open source. Something that traditional "business school" folks would never do. We're going to keep making Inbox better and better, but the code will always be available for you to run yourself.
We're planning to release a hosted SaaS version of Inbox (think Heroku), so you don't need to host +terabytes of email data or manage sync infrastructure. We haven't announced details around that yet, but feel free to email me if you'd like access to the preview. mg@inboxapp.com
I feel like "data scientist" is a title that grew out of the Fundamental Theorem of Employment, which states that you're usually hired to do a job that either (1) the boss man can't do for himself, or (2) the boss doesn't want to do. Type 1 work gets you respect and autonomy. Type 2 work will have you commoditized.
Software companies are satisfied with the job they've done at commoditizing programming talent but, at least for now, having a half-decent grasp of any specialty (e.g. machine learning, information retrieval) requiring mathematical firepower puts one solidly into Type-1 employment, which is where one wants to be.
"Data scientist" seems to be a way of saying, "yes, I code but I also know math, so use me for Type-1 work only".
> "Data scientist" seems to be a way of saying, "yes, I code but I also know math, so use me for Type-1 work only".
You make it sound like a bad thing? Despite the rah-rah I hear from programmers about how they are unique snowflakes, being only a programmer is like being a janitor. A prime way to get discarded at the age of 40. If I can make sure that I am valuable because I bring other things to the table (Math, Product vision, people skills), why on earth wouldn't I rebrand myself to better reflect that?
Not at all. That's my attitude as well. I don't want to waste my life on Type-2 work.
"I only want to do interesting work" sounds entitled after being conditioned by corporate mediocrity, but I think it's a reasonable attitude. Companies frown on self-assertion, preferring agreeable mediocrity, and I hate that. I tend to be honest about things.
You can't say, "I leave bosses and companies that assign me crappy work" on a job interview. I wish people could be honest about such things, but it's just not socially acceptable to speak the truth about anything that matters (e.g. politics, religion, sex, money, power, careers). On HN, I try to be as honest as I can be. Sorry if it comes off as obnoxious.
Despite the rah-rah I hear from programmers about how they are unique snowflakes, being only a programmer is like being a janitor. A prime way to get discarded at the age of 40.
Agree.
If I can make sure that I am valuable because I bring other things to the table (Math, Product vision, people skills), why on earth wouldn't I rebrand myself to better reflect that?
That's absolutely what you should be doing. If it's not obvious, I'm on the same side with people who say "I know math, so use me for Type-1 work only". I am one of them.
The reason the job distinction is toxic in many companies, however, is that software engineering should also be respected rather than commoditized. To me, the rush of people like you and me to get "superior" titles on our resumes is a sign that the business world doesn't respect "regular old" software engineering. That sucks, because the skills of a truly good software engineer are also quite important.
> software engineering should also be respected rather than commoditized.
I am not so sure anymore. When anyone who has done six weeks in a boot camp can call themselves a software engineer, the semantics of the word are lost.
> That sucks, because the skills of a truly good software engineer are also quite important.
The best people? They are valued and known to be valuable. For example, there is a guy in my company who works remote from the midwest. He is truly amazing. When he interviewed me, I quickly got the feeling that his machine learning skills were top notch. BUT, when I work with him, I realize that he is truly phenomenal. He can write code up and down the abstraction ladder. Good, solid fucking code. Hell, he can double up as an SRE and fix shit when he wants to. Sure, he is a "machine learning engineer". But he is much much more than just that title.
My personal side project, a MUD client for iPhone and iPad, is not even remotely profitable. That's right: online multiplayer text-based games. There are still thousands of them online today, set in fantasy, sci-fi, absurdist, and many other worlds!
I knew before I started that it wouldn't make much money. That's not why I wrote it; I wrote it because I wanted this app for myself.
It expands to fill much of my free time, driving my ROI even further negative, but I sure do enjoy it. :)
I first learned to program when I was 11 or 12 years old because I was playing MUDs and wanted one of my own so I could implement features and ideas I had. Best of luck. :)
I think I can also attribute my initial interest in programming to MUDs. Funny how, all these years later, they still give me satisfaction albeit through a much different tech stack. :)
Bummer...but also exciting, since Adhoc/Beta distributions and access could be massively improved by being handled first-party by Apple. Maybe now it will be!
I've long been using TF for adhoc beta distributions of my iOS apps. Looks like there are only two options left for that:
* Hockeyapp, starting at $10/month
* Host your own IPA on S3 or elsewhere.
The downside with the latter is where TF added value: per-build access settings, notifications, teams, and feedback. You'll have to approximate this now by mucking with which devices are listed in your provisioning profile.
I open-sourced my iOS build script recently. It'll take care of everything for you -- downloads your provisioning profile from Apple's dev center, builds, codesigns, archives, and uploads to S3. https://github.com/splinesoft/SSBuild
Apple could massively improve Adhoc and Beta distributions any time they wanted to. They didn't need Burstly or TestFlight for this. In other words, get ready to move off of TF and onto another platform.
Do check out my service AppBlade https://appblade.com, convenient timing that I was about to come out with some competitive pricing for ad-hoc developers.
You don't need to integrate the framework if you just want to distribute beta builds. Check the Beta Deploy section on the site.
We are also working on adding cocopods.
Also check out our service DeployGate, which was focused on Android but just have started a new Beta with iOS support this week.
If you join for our beta program now, you are eligible to keep everything free, forever. :)
Removing Android makes it nearly worthless for me. Also Apple doesn't have a good track record when it buys companies. The same thing happened with Logic - they immediately dropped Windows. Its rude and anti-competitive.
They already have gone away for Android. On iOS, it looks like they won't allow new apps to be created but existing apps may continue to upload new builds.
I don't see how TF removing Android support has anything to do with them going away. I just this moment created a new TF app for iOS and got a new app token/etc. Where are you seeing this "won't allow new apps to be created"?
It says on that page what happens; they'll stop accepting builds with old SDKs, or if you haven't used the SDK before. It doesn't say at all that they will be closing their service, or not accepting builds at all. Just looks like they are deprecating their SDK.
Travis CI (for now) is stuck on iOS 6, so you're out of luck if you're targeting 7. They expect to resolve this soon. You must also subscribe to a paid plan if you want Travis to build your private repo. That said, I use Travis for all of my iOS 6-compatible public cocoapods on Github.
Xcode 5's built-in Xcode bots require OS X Mavericks Server ($20) and, in my experience, has a very brittle setup if you're using Cocoapods. It's probably fine for simpler projects.
I've personally been running Jenkins locally. My build script:
- Downloads provisioning profiles from Apple's dev center using Cupertino[0]
- Builds and codesigns my app using Xctool[1]
- Archives the app with xcrun
- Builds my app again with the Testflight library, then uploads the result to TF
Edit: Jenkins has an Xcode plugin, though I don't use it (I use xctool instead). I do use Jenkins' Testflight plugin, which makes it very easy to upload your build to testflight and include the build's changelog in your release notes.
If your aim with this contest was to pilot something new and unique that might further distinguish YC, I suppose you've done just that, even if in the opposite direction. Sometimes karma is more than just a column in your database.
(Disclaimer: I did not vote.)