Introducing the IBM Swift Sandbox
developer.ibm.com
developer.ibm.com
Here is my experience with Bluemix:
1. We needed to get bills to send to our accounting department. There is no way to get this out of Bluemix. We needed to contact 5 different people and send 2 different support tickets.
2. At one point we couldn't log into our accounts, the authentication server was down.
3. The docker container doesn't always get internet. Also it sure as hell is guaranteed to not have internet if you restart it.
4. If you use their SAAS databases, then some of them you can connect to from the outside world, but some you can't. And there is no way of knowing which.
5. Just because IBM makes a product available doesn't mean it works. We used NodeRED together with the IBM developed database connectors for DashDB. That connector will timeout after ~24 hours and then not throw any errors when you keep writing to it. Took 3 days to figure this out and fix it.
6. Their deploy system is nice, pity it brings down your service for 5-10 minutes even for deploys that are literally 100 lines of java code.
7. It's painfully slow to push images to their docker hub. Took 3 hours to upload an image with ubuntu and java. And our uplink is 50mbit.
I am one of the people working on the IBM container service that's available as part of Bluemix. I am not here in any official capacity, just as someone who wants to understand what the pain points of our customers.
Let me start by saying that I understand your pain. As every product on the market, we have issues occasionally, such as the authentication one you mentioned or the networking. However, these are only exceptions and rarely affect our users, at least as far as we are aware. Did this happen repeatedly or was it a one time occurrence?
With regards to the ticketing system, I believe you are correct. Things are not as smooth as you or I would like them to be. I will pass this on to the management chain.
For the uploading speed of images, I also believe this may be quite rare, since I cannot remember hearing complaints about it. Did this happen on separate occasions?
With that being said, please send us tickets when something is not going the way you'd expect.
Thank you for your feedback!
The networking issue in docker happened for a few days. The "fix" from IBM (after a ticket) was for us to add a 30 second sleep to our containers. Needles to say this wasn't a fix we were happy with.
Tickets were also a huge hassle in the beginning. It was a 10 step process just to submit a ticket. It got better after a while.
We didn't file a ticket about the upload speed for images. I just remember sitting in a meeting realizing that the container had crashed, and when I restarted it it had no internet. So I thought, that while I was at it I would just push a new image with some bug fixes. That worked fine and I got a new container with internet, but pushing the image took more time than the meeting lasted without there being large changes to the image.
Amjad, I got started filing some issues against codemirror for better Swift support :) https://github.com/codemirror/CodeMirror/issues/3680
In fact, a quick check of Tiobe shows Objective C heading down fast with Swift about to pass it on its way up:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
No server is available to handle this request.
If you're writing server-side code for Linux/OSX, probably not quite yet. The language is nice, but it's only been available as open-source for a day now... the ecosystem you'd need to be productive in Swift isn't there yet.
(On the other hand, if you'd like to be involved in building that ecosystem, now's probably the time to jump in.)
I wouldn't want to use it for anything substantial, but if IBM's already hopping on the bandwagon it seems like a good language to learn for heavier use later on.
[1]: http://www.primatelabs.com/blog/2014/12/swift-performance/
In particular, the Swift Programming Language ebook isn't a bad starting point. The IBM Swift Sandbox looks like a nice little interactive environment to complement it, though, if you don't have access to a Mac to run Xcode.
[1] https://swift.org/documentation/ [2] https://developer.apple.com/swift/resources/
Here are some choices I think are interesting as new languages:
Elixir : interpreted / scalability / concurrency / fault tolerance/ friendly community
Rust : compiled / close to C speed / memory safety / concurrency
TypeScript : compiles to Javascript but with types / runs in the browser
Elm : compiles to Javascrtipt / functional / runs in the browser
That said, the edge cases are few and far between. TS is a fantastic language to work with.
It's open source. Works on Linux, Mac OS X, Android, iOS, Windows, etc. It has a good ecosystem and tooling built around it already but you can also tap into the C# ecosystem, if necessary.
It compares really well to Swift: http://www.slideshare.net/ScottWlaschin/swift-vslanguagex but even without that comparison, it's worth a look on its own.
Gain from the momentum and maybe turn a pet project into something bigger. I guess that's the benefit of having tens of thousands of developers...
func fdSet(fd: Int32, inout set: fd_set) {
let intOffset = Int(fd / 16)
let bitOffset: Int = Int(fd % 16)
let mask: Int = 1 << bitOffset
switch intOffset {
case 0: set.__fds_bits.0 = set.__fds_bits.0 | mask
case 1: set.__fds_bits.1 = set.__fds_bits.1 | mask
case 2: set.__fds_bits.2 = set.__fds_bits.2 | mask
case 3: set.__fds_bits.3 = set.__fds_bits.3 | mask
case 4: set.__fds_bits.4 = set.__fds_bits.4 | mask
case 5: set.__fds_bits.5 = set.__fds_bits.5 | mask
case 6: set.__fds_bits.6 = set.__fds_bits.6 | mask
case 7: set.__fds_bits.7 = set.__fds_bits.7 | mask
case 8: set.__fds_bits.8 = set.__fds_bits.8 | mask
case 9: set.__fds_bits.9 = set.__fds_bits.9 | mask
case 10: set.__fds_bits.10 = set.__fds_bits.10 | mask
case 11: set.__fds_bits.11 = set.__fds_bits.11 | mask
case 12: set.__fds_bits.12 = set.__fds_bits.12 | mask
case 13: set.__fds_bits.13 = set.__fds_bits.13 | mask
case 14: set.__fds_bits.14 = set.__fds_bits.14 | mask
case 15: set.__fds_bits.15 = set.__fds_bits.15 | mask
default: break
}
}I do not like it but at least be DRY as much as possible:
case 0: set.__fds_bits.0 |= mask
This is not ideal, but it comes up almost never.
As for your suggestion, that seems like an entirely stylistic thing. DRY is about not copy/pasting large chunks of code, not minimizing individual lines by using compound mutate/assign operators. I've never seen anyone say (before!) that something like `x = x + 1` violates DRY.
Collaboration enabled REPL is there too (enter 'swift' in the shell).