That was it. Thank you.
2,612 karma · joined May 15, 2008
I even wrote an authentication reverse proxy[1] in java in my spare time, so I can use that to publish my apps, and have SSO across all of them (until BrowserID becomes mainstream that is). This way I centralized the cookie auth problem, and don't need to care about it in every app.
I even tried
$ openssl s_client -connect hacks.mozilla.org:443
CONNECTED(00000003)
---
Certificate chain
0 s:/serialNumber=I1oZ-yurbFWiPu/xP8HIzW3f9mApQvMv/C=US/ST=California/L=Mountain View/O=Mozilla Corporation/OU=IT/CN=tbpl.mozilla.org
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
[...]
subject=/serialNumber=I1oZ-yurbFWiPu/xP8HIzW3f9mApQvMv/C=US/ST=California/L=Mountain View/O=Mozilla Corporation/OU=IT/CN=tbpl.mozilla.org
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
http://www.sslshopper.com/ssl-checker.html#hostname=hacks.mo...
Says the cert is ok, but my firefox complains:
hacks.mozilla.org uses an invalid security certificate.
The certificate is only valid for tbpl.mozilla.org
(Error code: ssl_error_bad_cert_domain)
I don't hate Java, but I hate to write the same application over and over again, one for every platform out there:
- the desktop web
- the mobile web
- iOS
- Android
- Windows Phone
- ...
With JS there is a little hope that we well be able someday to write the app once, and make it work on every device out there, if it is from Apple, Google, Microsoft, Samsung or whoever wants to enter the market next.
We are almost there, but we need hacks like PhoneGap/appMobi to make it work, and it's not optimal at the moment.
Let me make my point clearer: I was talking about the ability of downloading and installing apps freely from the internet. What I meant was a closed ecosystem where you can only use approved apps from the app store without the ability to install apps from third partys.
That does not mean that you can't use the terminal or XCode (if those are approved apps), or get a "developer license" to "unlock" your Mac.
But of course it's only speculation at this point.
A very simple js frontend sends get requests to wwwoosh, and some bash commands get executed to control a relays board that turns the lights on and of.
It's very simple, consumes almost no memory and is very reliable.
Yes you can accomplish that with Veil, but I agree, it would be nice if it was built in, but an add-on is ok too.
Sure you can. Skype did it, Hitachi¹ did it.
¹http://www.pgcon.org/2008/schedule/events/57.en.html
> properly handle JSON right now
Well it has V8 running on it.
> It also has a fixed schema
You don't need to use it like that if you don't want to.
spc_handle_request(req_headers, req_body, http_method, ...)
insert into table (a, b, c) values (to_json(req_body).a, to_json(req_body).b, to_json(req_body).c); to_json(select * from emp);
They don't deny it. They say that "At this time there is no evidence indicating that an FBI laptop was compromised". That's different. The evidence is just not here at this time.
And then JavaScript driven feature detection came to be, and everyone thought it was a good idea. And the people wrung their hands and wept
>> rows/objects that match multiple restrictions, ORM turns into a
>> migrane of epic proportions.
>
> Perhaps you're doing it wrong. Put the complex query in a proc or
> view, and use the ORM to map the result set into memory. Using an ORM
> doesn't mean not using SQL when it works better.
that's what he sad: use sql when it works better. if you put it in a proc, a view or your application makes no difference.
I remember the times I had to hack around for days to get some particular piece of hardware to work. That happens less and less, and now most of the stuff I buy just works.
Video cards and capture cards are the big exception for now, they somehow work sometimes, but this is getting better every day, and this news takes us in that direction even more.
If that were true, to install google chrome/earth or whatever on ubuntu I would have to
- get google apt repository
- add it to my list of sources
- import google repository key
- run apt-get update
- run apt-get install google earth
instead of simply doubleclicking on the the downloaded deb.
Almost directly. The JS frontend calls something like mod_libpq¹, or a very simple node.js "proxy". Something that just gets incoming http requests, executes stored procedures and sends back the response. A reverse proxy between the JS client and Postgres. That proxy can be very generic and reused between applications. All logic would live in the db.
You have a form, you enter data, the data is somehow aggregated and presented to you in some other form or the data is sent off to some other service that then processes the data in some other way.
Removing a layer between the JS frontend and the DB just simplifies the whole stack: if postgres can do something like
(select * from employees).to_json
var record = {"empId": 2, "empName": "Franz"}
insert into employees (emp_id, emp_name) values (record.empId, record.empName);
I don't. I just repeated what Nelson Mattos wrote on his blog.
"a team of people working on a Google project improperly used Mocality’s data and misrepresented our relationship with Mocality to encourage customers to create new websites."
This year my happiest moment was when I finished the 70km ultratail in the middle of wonderful mountains. When I arrived I was tired, but I felt like I was the boss of the world! :)