Making a hash of the release is just a small part of it (and is the first part of what they are doing).
The trick is to be confident that you're getting the same hash as everyone else - and that's what requiring a proof that it be added to a CT logs gives you some level of assurance about.
APNS2 has a simpler interface and doesn't do things like generate website packages etc.
APNS2 has better test coverage, and handles errors in a more go-like way.
(Returns a response if a documented response was received from Apple, or an error where an unexpected error occurs.)
We are running this in production at http://carnival.io to send millions of notifications,
to my knowledge buford has not been tested in production yet.
From a first look APNS2 seems to add very little value over bufort which we are running in production very successfully. I really wonder how you manage to send millions of notifications (over which period of time?) without much boilerplate code.
Currently this is just Wordpress, but we are (at some point, not when) moving to a static HTML generator. I'm not close to the doc generation/writing, so I don't know too much.
That depends on what you mean by faster. For CPU-bound work, JRuby is almost always faster. The JVM is very good at optimizing. However, the best performance doesn't kick in until the JVM is sufficiently warmed up, which means JRuby shines mostly for long-running tasks. Warming up can take a few minutes, although some people tell me that I should warm up for half an hour (!).
On the flip side, JRuby starts much more slowly than MRI. This is a general Java problem: startup times are problematic. Also, code reloading performance may be worse than MRI, so things may be slow in development. JRuby is optimized for production-level long-running workloads. So something like 'rake' will likely take longer with JRuby.
We've added a --dev flag to JRuby that attempts to turn on fast-starting flags in JRuby and the JVM to reduce startup time. It can be as much as twice as fast.
We continue to try to improve startup performance, and hopefully over the next year we can close the gap a bit more.
In practice I've found the start-up times aren't all that different. The drag is more pronounced on older hardware, though. A current i5 or i7 system with an SSD is usually roughly the same.
That is very contrary to my experience. A Rake task in a Rails project almost always takes somewhere like 15-20 seconds just to start up (on MRI it's around 2-5). Just today, I tried to run the Middleman static site generator. Where on MRI, Middleman starts building after around 3 seconds, on JRuby it starts building after around 10 seconds. And I'm on a 2012 Macbook Air.
The real advantage comes from the fact that JRuby isn't enslaved to a GIL like MRI, so you get JVM threads out of the box. Even with the JIT, JRuby (at least 1.7) isn't appreciably faster than MRI when running a single-threaded app: http://www.isrubyfastyet.com/
JRuby used to be much faster than MRI (definitely so when MRI 1.8 was current), but MRI has gotten better faster than JRuby, and IIRC, its now mostly a mixed bag based on workload, particular application design choices, etc.
That's generally not true. MRI's straight-line performance has not improved as fast as JRuby's, and if we're ever slower than MRI it's generally something we're doing wrong. When we're doing things right, performance can be anywhere from two to ten times faster than MRI.
It is a stated goal of the JRuby project to meet or exceed MRI performance. The team will actually accept issues/bugs if you can provide a (well structured and isolated) benchmark illustrating a performance deficiency relative to MRI.
What I read is that it's faster for long running applications (example: web apps) because the JIT can optimize the code. It should be slower for anything else, example: tests (very unfortunately).
I don't know what the edit-reload-check workflow could be with JRuby and how well it can integrate with editors (few Rubyist use IDEs, http://www.sitepoint.com/ides-rubyists-use/).
Anyway, I'm doing a bundle install with jruby on a Rails project right now. Let's see if it completes and passes the tests.
I've been doing some progresses but there are a few (almost) show stoppers.
One is that startup is really slow.
rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with.
Second one: still immature. The PostgreSQL adapter warns
NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2 support - check http://bit.ly/jruby-42 for starters
Not something I want in production.
Third one, now I'm stuck with the JDBC adapter not connecting to my developement PostgreSQL over a unix domain socket. Maybe it can't (perhaps JDBC does only TCP/IP) and I have to reconfigure PostgreSQL to accept connection to 127.0.0.1:5432. That means any other application I'm working with won't work anymore and I should reconfigure them.
Summing up all together I'm not particularly eager to keep testing JRuby. Maybe somebody will solve those problems. I'll give another try to it next July.
It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no?
The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.
JRUBY_OPTS="--dev" lowered the startup time to 12 second, basically on par with MRI. Thanks! I googled you suggestion and I found https://github.com/jruby/jruby/wiki/Improving-startup-time I'll try a few suggestions that look like doing with spring does (Theine and Drip).
My other problems are with JDBC but if database drivers don't support Ruby's largest use case (Rails with ActiveRecord) probably JRuby will be negatively impacted. This is about the "ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC". The other one (unix domain socket) is a minor issue but any small nuisance loses developers along the way.
FWIW, I've never had any luck with Theine or Drip. But --dev is good stuff - it basically turns off the JIT and invokedynamic, which are great for long-running processes but not that useful for shorter script runs or consoles. JRuby defaults to "good for long-running processes" mode, which is great for production but less useful when running short-lived tasks.
Yeah, certainly understood WRT JDBC. But, as nirvdrum pointed out elsewhere in the thread, you might look at Sequel rather than AR if you do want to do JRuby stuff and AR-JDBC is holding you back - it's well-supported and I know lots of folks use it well.
The domain sockets thing is unfortunate, but AFAIK, they just aren't supported by JDBC.
I realized that PostgreSQL can listen to both the Unix domain socket and a TCP address so I've been able to run the tests. I'm stuck now with the integration tests failing because they can't run the Selenium Chrome webdriver. I opened an issue. I also have some failed tests on a model, still didn't looked at them.
I won't convert this app to Sequel only to check that it works with JRuby. Neither I'll write the next one with Sequel. If JRuby doesn't handle AR it's over for me. It's JRuby that must be compatible with MRI (the reference implementation of the language), not the other way around. That until the majority of rubyists use JRuby as default. It's too risky.
At least with the previous JRuby, for us the answer is "usually no." If you do any large string ops (hello JSON), or parsing, or use any ruby gems which use exception handling for flow control (which is cheap in MRI, but like 9ms per exception in JRuby) in a loop then you will be slower. Also, SSL connection negotiation is exceedingly slow in JRuby 1.7x (like 100ms) and this made our microservices tough. Using HTTP Client with keepalives helped with this.
In a hello world, you might come out ahead in 1.7.x. Maybe 9000 is better?
I wrote Manticore (https://github.com/cheald/manticore) because of my dissatisfaction with Ruby HTTP clients under JRuby; it uses the Apache HTTPComponents (completely sidestepping Ruby's stdlib http/networking stuff) and is extremely fast. It might be worth looking into for you.
Do you have anything you can point at regarding String performance? Everything I've seen shows JRuby being faster than MRI. But I'm looking to see if we can make it even faster than it currently is. Any pathological cases would be incredibly helpful.
I can send you an example. Can I drop you an email? I think also that we are friends on linkedin, coincidentally. I can message you there (if that is a useful way to get in touch?).
They're a mixed bag because they're benchmarking libraries more than they're benchmarking runtimes. Often the JRuby-specific versions of libraries (e.g. activerecord-jdbc) do not get the same performance attention as the ones for MRI, and as a result they perform worse.
I know this is small consolation, but everything in the JRuby ecosystem is continuing to improve every day. When there's specific reproducible cases where we're slower, we take them very seriously.
You don't have to spawn a separate instance for each CPU core. Granted there are web servers that take care of some of that by having multiple workers.
What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.
Because the C extension API isn't supported. Or to put it another way, you can call C libraries from JRuby, but you can't write C that calls JRuby. If you want to do that, you would replace it with a Java extension, instead. It's possible to offer "native extensions" for both MRI and JRuby from a gem by providing both via C and Java extensions, though.
Print the CLA, sign it and scan it (or use a camera to photograph it) and e-mail it to hello(at)robovm.com. Include your GitHub user name in the e-mail.
A bit wacky indeed. For what it's worth when dealing with this stuff I use Apple's Preview App's signature feature. It's pretty neat. You take a photo of your signature with your webcam and place/resize it as necessary. I create a new signature each time (paranoia) but if you have to do this a lot you can have Preview save it for later.
they built a wooden model to demonstrate their answer — although Bozóki notes
that the model doesn’t verify the result because manufacturing errors
are much greater than any errors the computer could have made.
What's the point, when its not practically possible?
What's the point of what? Physical models have imperfections and distortions, so to absolutely know the answer you need the mathematics. Then having done the mathematics it's satisfying to build the physical model, to see it and to hold it.
Can you clarify your question? Try to avoid the word "it" because the referent might not be obvious.
The wooden model "works", eg they all touch. But it could be slightly less than perfect and you wouldn't be able to tell, mathematicians care about these things :)
