This is such a shock to me! I've been a Final customer for a year or so now, and I have absolutely loved their product. I told all of my friends about it. I'm so sad to hear they're shutting down, and very curious as to why.
For me, the real draw was how easy it is to setup a cluster with high availability and automatic failover. Having used MySQL in production on a mission critical web app for years, failing over between data centers and setting up replication again every time there was some kind of hiccup got very old very fast.
We're writing to let you know that the group you tried to contact (oss) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:
* You might have spelled or formatted the group name incorrectly.
* The owner of the group may have removed this group.
* You may need to join the group before receiving permission to post.
* This group may not be open to posting.
My company's product backend is written in PHP. I'm currently rewriting it, and when I started the process, I tried doing it in Node.js because 1) the possibility of client/server code sharing and 2) that's what all the cool kids were doing. That lasted all of a few weeks before the async nature of Node made my head nearly explode. I scraped that and went back to PHP where you can depend on code being executed line-by-line, synchronously, without hacks.
As a language, PHP definitely has some warts. But, it's come a long way, and it keeps getting better all the time.
Personally, I don't think it deserves all the hate it gets. Some criticism is warranted, but definitely not all of it. I think a lot of it stems from the fact that the language is so easy to learn and lets you do things your own way, which (at least in the early days) led to a lot of newbies writing insecure code. See: register_globals (since removed).
That all said, I love PHP. It's simple, yet powerful. It grows with you, and most importantly, it gets the job done.
I have yet to see a good example where this was worth even considering. Model validation seems to be the only real use case and there are so many potential non-JS based clients that you'll likely need a more general solution for that problem anyway. And even for JS based clients, usually the big pain is the UI logic for showing users the errors and helping them correct it, stuff you won't use on the server side.
I had one example of client/server sharing with C#. It was ASP.NET on the server and Unity3d client: all the data model objects were shared and serialization in both direction was a breeze.
In client/server settings with a .NET frontend and a .NET WPF client you can get a lot of code sharing. But in typical web apps with javascript frontend and a a Javascript server I don't think there will ever be much sharing.
We share model validation, internationalisation functions / string parsing and formatting values (language strings, datetime formats, currencies, etc), access rules, configuration settings, views and constants at least.. I've also had a few situations where we've moved client side code to the server, and not having to rewrite from scratch is nice.
None of these are huge issues to solve with a separate language on the server. But for our projects it's been a time saver.
It's useful for views, I've done it with React. But yes more for demo apps than in production, at some point things break down because you can't write both server-side and client-side code handling for every UI state.
> you can't write both server-side and client-side code handling for every UI state
I'm interested, what do you mean? Can you give an example?
As far as I can tell, whatever you serve to the client is also available server-side. You render it there, send it down the pipe as static HTML and hydrate it client-side seamlessly.
Except for specific cases where client's local storage has a significant amount of data, of course, but that seems more like the exception than the norm.
Like if you have an error saying "no results for this book title", you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data), and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different. I think if you try to be very fastidious about making everything work without JS you will have two code paths for many things.
Not sure I agree with the example at all. Maybe I didn't understand?
> you'd have logic that sends JSON and checks that, and on the server side you'd need logic that checks the POST request and checks that
Sending != receiving. That's not duplicate code, it's just different functionality.
> (and there'd be subtle differences in the variable format between the JSON & regular HTML POST data)
I don't see why.
> and then maybe the way the UI element would be displayed in JS vs in the server-side HTML is also different.
Why would you do that? Inconsistent UI is bad. I'd expect the same UI whether I got the page via URL or via AJAX.
What JS code sharing gives you is the same server-side and client-side rendering. E.g. you can send fully rendered HTML or just JSON depending on the Accept header, saving on data and full-page refreshes but still having SEO (and not having to wait for client-side to render).
You can also share the same model in both environments (like having the same Book class, which you'd have to code twice in JS and whatever server-side language you use).
Trust me, although I've written a tutorial about this[1], it's not that straightforward to do for a live site :) To put it another way, making the same app work with and without JS isn't made much easier even if you use React server-side rendering. But if you make something like that I'd be happy to check it out (contact info in profile.)
You can make nodejs front facing, use the same code for views on server and client, and still defer your real backend (any language, probably APIs only) behind nodejs.
If it's a pure API (no HTML templating involved) I would use Go today. I personally find nodejs async programming obnoxious. Go isn't perfect (the type system is extremely limited, though It can be cheesed through reflection) but you have access to powerful concurrent constructs without having to write callbacks, promises and all that bullshit. Async programming is fine when it comes to GUI programming (it makes sense to write click event handlers). Having to perform an HTTP request in the backend asynchronously does not. Gimme threads,queues and pools and let me think synchronously.
Now if your backend is about serving some HTML files and forms, keep using PHP,there is very little reason to rewrite it in another language, that's where PHP shines.
Syntactically, PHP is atrocious. But it has a lot of very good qualities as a web environment, which has nothing to do with the syntax of the language.
Easy to use documentation. "Batteries included" standard library that specifically caters to web dev. Shared-nothing architecture. No separate compilation step. Easy deployment via source code. Ability to use PHP files as configs and templates. In more recent times, autoloaders and APC cache.
As far the language goes, I also like their approach to dynamic invocations via __call. Very simple and powerful.
Saying "<PHP's syntax> is atrocious" has always been spurious (or simply mischaracterized as "I like X better"). Compared to what? C or Erlang or Haskell? It's really damaging to credibility to start with flamebaiting.
It's just that you are used to PHP. Async callbacks can be flattened with either ES6 generators or async/await by using TypeScript (Both of which require transpiling. nodejs alone would understand ES6 without it though.)
It's far better to do background tasks with its parallel capability.
The bigger concern is nodejs app server holds states between requests unlike PHP and as such when you define a static property on a class, it's held between all subsequent requests not giving you a clean state.
I'm trying to get used to nodejs for frontend as well but you should delegate db logics down to database triggers, so you don't have to duplicate logics between different languages if you have multiple or change language later on. Same goes for keeping config files in ini format or other language agnostic format.
> Async callbacks can be flattened with either ES6 generators or async/await by using TypeScript (Both of which require transpiling. nodejs alone would understand ES6 without it though.)
I'm no stranger to Node.js. We use it in production for all of our real-time/async stuff. The new ES6 features async/await are cool and all, but it's a late addition to a language that was clearly not designed for synchronous code. If you use them, you just end up with bloated, complex code. For an API, I think Node.js is the wrong tool for the job, personally. PHP is a better fit, IMHO. For real-time/async stuff, it's a different story.
While Java devs are fighting with the eclipse issue of the day, generating wsdls, deploying wars, making annotated glorified structs for typed json/xml/both (except in some cases when they just go with a Map<Map<....,String>,String>), and so forth, those other dynamic languages get out of the developer's way and let them solve their problem with less fuss.
Java's not a terrible option. But it's rarely the best option, especially for Right Now, though it may become the best option later when enough competing concerns have cropped up.
Here you don't even have to write code for controllers or db connections for basic CRUD HATEOAS REST service. Spring takes care of it. The model still needs getters and setters, but you can avoid this with Lombok
If all you need is a basic CRUD service, there are even easier options in the PHP/Rails/etc. world. If you have a schema for your data, it's pretty much one command away to generate such a CRUD service. Some of them even give you a nice looking out of the box web interface too. So you're not really selling me... And my day job is in Java, we're pretty modern with Java 8, Jetty 9, Spring, etc. but it still ends up being something like this: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...
Spring Boot may be a bit nicer than the most out of the way method I used years ago (now at https://github.com/stoicflame/enunciate/wiki) which did use Spring for some things, but it's really still far away from what dynamic languages and their ecosystems offer.
Honestly, I think just because it's so exceptionally un-cool. PHP may not be that cool either, but Facebook uses (has used?) it, and it's at least not as strict and "enterprise-y" as Java.
> the async nature of Node made my head nearly explode.
There is a reason that paradigm exists, other than to make development frustrating. How do you avoid thread exhaustion in PHP if you synchronously block on a line that could take a really long time to complete? (Making a request to an external HTTP service, for example)
If you have difficulty concentrating, are easily distracted, impulsive (i.e. checks Hacker News a lot), are irritable, etc, you might look into whether you have ADD/ADHD.
I had all of those symptoms, but never considered I might have ADD until a few months ago. My doctor had me try Adderall, and the difference has been like night and day.
I'm not saying you have ADD or ADHD. I'm not a doctor. But just based off of what you said, I wanted to mention it, because I wish someone had mentioned it to me like 10 years ago.
The web has been crafted to pray on our most basic instincts to keep us coming back for more, more, more. Being addicted to the internet is more indicative of the good work by 'engagement engineers' then of a need for amphetamines.
This is literally me. I might need to go to the doctor. It's especially telling that I miss appointments frequently and have had work issues with completing people's sentences or not allowing someone to finish talking before I say something. A lot of people also tell me I'm not listening to them talk.
>completing people's sentences or not allowing someone to finish talking before I say something
That used to be me too. After I started taking medication, I was a little surprised to notice I became a lot more patient with people. Specifically, I didn't feel the need to hurry social interactions along, etc.
>and even law enforcement cannot look up the cell tower logs to see where it's been.
I'm not so sure about that...
I worked at a TV news station in a major city where police told us they could track cell phones that were turned off. IIRC, it came up during an interview after they apprehended a suspect in a big rape/murder case. The suspect's phone was off, but they were able to track him. They told us they didn't really want the public to know they could do this, but it seems it's too late for that [1].
I'm not sure what the limitations are-- whether it'll work if the battery is removed (maybe there's amother battery?) or whether it only works with certain phones.
When the phone is off it is off.
Same goes with flight mode.
The NSA* or any other similar actor can load malware to your phone that would prevent it from being completely turned off, the police most likely cannot.
The police does have a vested interest in making the public think that turning the phone off is pointless.
*on older phones like late 90's very early 2000's there was enough power leaking from from the antenna into the modem part that you could ping turned off phones remotely even if the battery was removed I've seen this in action.
This doesn't or shouldn't work on new phones which require considerably more power and have very complicated hardware.
on older phones like late 90's very early 2000's there was enough power leaking from from the antenna into the modem part that you could ping turned off phones remotely even if the battery was removed I've seen this in action
I don't see how that could work - even if power through the antenna did cause the phone to transmit something, more than the radio would have to be powered up to get the phone to return any kind of identifier. But I'm skeptical that any transmitter could be powered through the antenna like that.
I could believe that if you transmit enough power that some sort of oscillation would occur in the phone to return a signal that can be detected, but I don't see how you could determine what phone returned that signal.
It wasn't transmitting a proper cell signal, it was transmitting something that they could detect.
I would assume that you would profile phones (of a certain make and model) and based on the return signal identify them.
This was used in the early days of in places where there wasn't high cellphone density to begin with.
I don't think this actually violates any FCC regulations given the right circumstances a can of coke can probably be induced to create enough backscatter to be trackable via RF.
>The police does have a vested interest in making the public think that turning the phone off is pointless.
An interesting point, but...
If I were a criminal (I am not), and I were going to commit a crime (I am not), and I knew turning off my phone was pointless because the police can still track it, then I would just leave my phone at home, or give it to a friend.
It's very old phones, with external antennas the power came from the same place that the power came from to say power the LED in the aftermarket NOKIA antennas that would light up when you are getting a call or a text - wireless power.
The phone had enough leakage to modulate the return signal sufficiently to be detected, it would not be the same thing as tracking a phone via its normal cellular signal it would just indicate the presence of one.
Those aftermarket lighty-uppy things work by sensing your phone's response burst, which is a much stronger signal, being driven by the phone's battery, and radiated from the very nearby antenna.
I do believe that you can induce a signal in a powered-off phone that can be detected nearby (several feet), by virtue of the tuned antenna if nothing else. I'm skeptical of the claim that a normal arbitrarily-distant cell transmission could do so. Regardless, I do not believe the induced signal could be detected back at the cell tower.
This would be wireless power. Not possible, at the levels and ranges asserted.
Believe what you want but at least read it through first.
This isn't about powering a cell phone via wireless power and make it connect to a cell tower this is about inducing enough power into the cell phone's RF parts to make it modulate the signal sufficiently to be able to be picked up.
Essentially this isn't that much different than the passive wifi or any other backscatter communication based system.
I've seen this demonstrated around 5 years ago at an Intelligence Technology seminar open to the public at the intelligence community heritage museum, it was done across the room during a demonstration which showed active and passive phone tracking techniques (they put the phones in and out of a faraday cages during the demonstration).
The phone that was used in the demonstration for the "powerless" tracking was a very old Ericsson (before it became Sony Ericsson) phone from the mid to late 90's, during that demonstration we've also been told that this method of tracking became obsolete around the early 2000's.
They did not elaborate exactly what ranges this work on but what they said is that the emitter and receiver were usually separated in order to accommodate operational requirements.
As I read it, that's a fine way to detect the presence of a cell phone. It might be able to discriminate between several models of cell phones. But it will not be able to identify a specific cell phone.
Yes, I said it was used to track cell phones in low density areas back when they were simply enough for this trick to work, what I assume is that if someone back then had a cell phone/radio phone/sat phone or anything similar with a susceptible transmitter in the middle of nowhere-stan you could probably identify them via other means, or at least be able to classify them sufficiently.
> When the phone is off it is off. Same goes with flight mode.
You're forgetting about the baseband. Modern phones have a secondary processor loaded with proprietary software that has a secondary battery soldered on. You can't turn that device off, and it has the ability to phone home. Even removing the battery won't help you.
No i didn't forget about the baseband, hence the NSA grade malware.
That said I haven't seen a single phone that when in airplane mode or off showed any signs of transmitting anything.
I've also done testing with RF fuzzing phones and nothing happened.
Other people did more analysis including power consumption monitoring etc. and there is no "on by default" home phone feature on basebands.
Can a base band be backdoored? sure, can the police do that most likely not, if anything the "quality" of commercial cellphone malware is fairly low most of it requires physical access to the phone or social engineering to install.
US Law enforcement relies mostly on cell provider and IMSI catcher based tracking, some departments might have access to commercial RAT products ala FinFisher but I have seen no evidence that anyone has access to baseband based exploits.
If anything it seems that even state actors do not have turn key solutions for remotely accessing the basebands of commercial mobile phones and often have to resort to compromising the supply chain to launch targeted attacks.
So yes the baseband is a CPU, it's probably considerably less secure than you would want, but saying that every baseband or even the top 10 most popular ones are or can be compromised at will doesn't pass the current smell test.
When you worked at that TV news station, were Blackberry phones prevalent? Blackberrys had two types of "off" -- one type periodically checks the network for texts and the other is an actual off.
I don't buy it. The top quora response you link to makes claims that tracking happens when off, but it's sources make no such claims. Specifically, I highly doubt that GPS is useful towards tracking an off phone.
