Hacker Newsnew | past | comments | ask | show | jobs | submit | kaeawc's commentslogin

Sorry to hear that, can imagine the frustration.


We had 20 minutes notice, and then everyone was kicked out of the Slack support channel and API responses simply died. What the actual fuck. They have mobile client SDKs out in the wild that are now just eating up battery life as they retry an impossible query forever.


That sucks. We (Sift Science) have been building something similar for 7 years and aren’t going anywhere. If we can help, please ping me - jason at siftscience dot com


> We (Sift Science) have been building something similar for 7 years and aren’t going anywhere.

But that doesn't come with any actual guarantees does it?


> and aren’t going anywhere

Yet... that you know of.

Nothing specific against Sift Science whatsoever in my comment, but many, many times this sentiment has been conveyed by companies and it rings hollow IMO. There are a lot of different ways a company can change or disappear at some unforeseen point in the future, and claims that "you can trust us to be here forever" do not carry much weight for the large group of experienced users, devs, management, etc who have been burned multiple times.


So are you implying that you should never enter into a business relationship with another company?

Clearly, you need to always be prepared for your partner to go away, but you still have to work with other companies.


I think the parent commenter is just saying that it's not something you can actually believe, just like a company saying they'll never sell your data.

Sure, that's the intention but when someone comes around waving a checkbook, they can in turn buy you and shut you down, sell your customers' info, etc. Sure, its not YOU allowing that to happen but by ceding control you essentially allowed that to happen.


"You can trust us to be here (until enough money comes our way)" is just how it is for most businesses like this. An unfortunate, and in my opinion largely unresolvable, side effect of an ecosystem where specific useful tools are hard enough to create and manage that full companies have to be formed around them.


What kind of guarantee would be satisfying?


A third party code escrow account with instructions on how to build the service and a contract that specifies conditions when a customer gets access to that escrow.

I've been on both the customer and service end of such agreements.


Is there a popular provider for doing this? It sounds like a lot of work to find a solution in which both parties trust (both technically versed and reliability wise). A common notary probably wouldn't cut it, right?


Both companies I’ve worked for - as a client and a customer - used Iron Mountain.

http://www.ironmountain.com/information-management/software-...


There's a bunch of companies doing it, some dedicated, some as part of larger related offerings. E.g. I know NCC Group (large IT security company) does offer it, TÜV (which does all kinds of certification and compliance work), ...


The contract should specify. The contract probably was sided on smytes favor. Screwing even paying customers.

You can have a contract where you specify indemnification of damage in case the business ceases operations, goes bankrupt, get acquired, etc...


A guarantee is only as good as the guarantor. A guarantor can be a company providing a service, as well as all sorts of assorted guarantees about said service.

In time, the situation can change. The product can get sold. Cash can be spent. The guarantor can no longer make good on its guarantees.

You're back to square one where the guarantees are as worthless as the original service.

You need 3rd party backing (insurance) in such situations, but that costs money. This money is a cost which makes competing against unbacked entities tougher.

In most cases, you can not have 100% foolproof guarantees of anything. The closest I can think of is governments standing behind their banking institutions. Even there though, governments have defaulted on their guarantees.

The world is not a stable, perfect, and cut-and-dry place as many would like to believe. It is dynamic, and ultimately backed by trust.


It's much harder to mitigate this kind of risk in the world of services as against purchased software.

The problem has always been present especially when larger slower moving companies buy from smaller, riskier, companies.

In the days of software, code escrow was possible to mitigate some of this kind of risk. That's still got it's costs but can be an effective hedge against a supplier going bust.


The parent comment is justified.

While you can have a contract that indemnifies that isn’t going to help your going concerns when the other party just pulls the plug.


I think company bylaws that prevent a 'triangle merger' like this might be useful.


what's stopping the company owners -who are generally the ones executing such a merger- from changing the bylaws ?


Do you have a high level overview of what I’d need to do to get started? Are there any specific areas you specialise in as opposed to general users and what information will I need to share with you?


Shockingly bad. I wonder if they shitcanned the whole technical team and they turned the lights off on the way out. Not that it’s really much better but at least it wouldn’t make sense.


And there will be absolutely no consequence to these actions. Completely messed up!


I hope you think over that design the next time. Put it in the cloud they said ...


I actually ripped out Smyte's Android SDK because of how bad it was and replaced it with my own implementation against their API which has a hard limit on retries. But I imagine that other customers were using their SDK and still have live apps out there using it... not good :/


I am a developer of an app that makes use of Facebook friend permissions and have seen the various API changes they have made since 2014.

Applications using Facebook Graph 2.+ (which is the only option since Spring 2015 or so) who access friend data may only access data of friends who have also given consent to your app. So if A and C log into a Facebook app, and A is friends with B and C, the app can only be aware that A and C exist. This is true of legacy and new Facebook applications. It used to be possible to get basically everything about B (name, age, gender, photo, etc), but that all got shut down when Graph API 1.0 was discontinued. If this is somehow not the case for some Facebook apps that got special permission or there is a hack to get at the data, that would be a huge breach of trust.


They haven't got around that, it's just that this data "breach" happened before 2015 when the old API was removed.


Is this correct? Because all this time I was wondering about this scandal: apparently, this all started because someone had some app or website which got downloaded by a few hundred thousand FB users (who gave access to their info), and somehow they turned that into data of 50M users. And I also am well aware the current FB API doesn't allow you to get info about your friends if only you give permissions to an app. That this "breach" happened some time ago, when API permissions were different, would make a lot of sense to me.


TL;DR (which someone never gets reported):

Before 2015 Facebook apps could access the data of your friends if you gave it permission. Your friends didn't need to give explicit permission (though there were never-used settings to block access).

Some academic dude made a personality test app that harvested the data from all of the friends of people who used it. He paid lots of people (almost all American) on Amazon's Mechanical Turk to use it and harvested their data and the data of their friends.

He sold that data to Cambridge Analytica. This was in 2012 I think. Facebook removed that version of the Friends API in 2015 so this is no longer possible.


That’s actually the point of my post. I have been developing Facebook apps since the very beginning of the developer platform, but stopped because the new rules were so restrictive that they made apps useless. There is no point to developing social network apps that can’t involve the user’s social network.

Since all apps have these restrictions, I don’t believe that any apps at issue here had special permissions. However, it is possible that they scraped public data and were assisted in being pointed to which data to scrape by the direct profile data they obtained through the apps. Enough friends lists etc. are public to make this potentially beneficial.

No specs have been released about CA’s “psychographic profiling”. We don’t know the extent of the data that they had access to, what data went into it (perhaps it was based on name and friends list only, which are mostly public etc.). So until we know more, we can only assume that these apps had the same constraints that all others do.


Whoa. Why is this post so buried?


> If there is never enough time to refactor and new features are always being pushed

That is a sign of bad culture, both in engineering and product. Whether its starting a green-field project in a scrappy startup or building yet-another-feature for an established product if the estimates are constantly redlining everyone's available time and never giving thought to maintenance, QA, testing, code review, and testing then of course it will always feel like that. When estimates include that stuff and you show product you can ship features more reliably more often in the long run, they buy into that. If they don't buy into that they are either very delusional, have only worked with absolutely perfect people, or they utterly do not care how many extra hours / stress the lack of quality causes you / the team / the company.


And in a bad culture other priorities can be more important. As an employee your job is to adapt and support the business. Writing tests in a culture that doesn't value the time spent is not helpful.


The problem is that the "bad culture" wastes more time and mental strain on addressing the consequences of the lack of tests than it would spend maintaining a proper test suite.

This waste exhausts morale.


Have you gone to production with it yet for your backend? Curious Android dev here.


We use it in production for a Storm-based ETL pipeline. We've not had any problems that have been related to our use of Kotlin.


Not yet, but zero issues so far. Currently running Spring Boot 2M7 on AWS EB just fine. I was surprised how smooth it went.


Correction: found an issue with bean validation.

https://github.com/spring-projects/spring-boot/issues/11343


And it turns out it wasn't really an issue, just unintuitive. Documentation has been updated.


Worked on at least 2 projects using it in production (backend) zero language issues


I generally agree, except if you click on "Home" it shows a sad PHP 404


I figured out how to undo the CSS that hides the release button and had some fun...

https://imgur.com/a/QIEv9


The coding of this page is absolutely broken beyond any reasonable expectation. Still fun tho.


You don't know how broken the CSS is until you've reached deep conversation...

https://imgur.com/a/o2gTo


Absolutely broken. After text flowing out of the chat box, I had to manipulate CSS to get rid of the annoying background image; "hack-bg.jpg"!

I think the developers never expected a longer conversation to happen even though one side is a superintelligent AI trying to break free. Ot they were counting on impatience and limited attention spans of humans behind the experiment which don't leave any need for proper scrolling.


Thanks for the catch!


In Kotlin it's much more common to write the following, which is exclusive:

   count.forEach {
      // do things
   }


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: