I'd love something like this that handled in-app purchased subscriptions. There's a bunch of annoying parts of dealing with the app store SDK's & verifying transactions, handling refunds etc. We have a combination of online credit card purchases and in-app ones, it seems like there's an opening for some tool to handle the in-app part as well.
I've written C# for most of my career, and have in the last couple of years been exploring functional programming. I started learning Scala, and getting involved in the community and I found it to be quite interesting.
Something I find different is that most C# developers like writing C#, they may dislike many other parts of the ecosystem, but they generally enjoy the language. However with Scala developers, I find that many of them seem to dislike the language.
To cast a broad stereotypical brush, it seems like there are 2 main groups of Scala developers. There's those who are really into FP, and would love to be getting paid to write Haskell all day, but unfortunately Scala is the only option they can convince their employer to adopt. So they begrudgingly choose it because it has some of what they want, but they are forever wishing it was better & making their frustrations known.
Then there's the other side, which are developers coming from Java (or other OO languages) after hearing about the benefits of FP/Scala. They're either not using Scala professionally, but want to learn, or are just starting to use it at work. They are much more enthusiastic about the language.
Unfortunately, the first group are often more vocal, and it puts off newcomers.
Yes - https://events.google.com/io2015/offsite (scroll down). Currently it says "We're compiling a map of I/O Extended events in your area. Check back to find one close to you."
Ah man, I've been working on http://sploria.com/ for a while, leading up to launching an MVP soon and hadn't heard of TourstEye. Had a look at the app and the 'experiences' part is almost exactly what we've been building, damn :(
Congrats on your success with the product though, it's really beautiful!
One option is to alternatively switch between both broadcasts on a single radio.
You broadcast a single iBeacon-only message, sleep for a few hundred miliseconds and then broadcast a new AltBeacon message.
The beacon does this so quickly, that it's usually sending out two or three of both kind of messages every second. It's effectively an iBeacon + AltBeacon in one device.
You can use this example to send this example code on github to run multiple advertisers. (May be a bit of overkill to just send 2 kinds of beacons but does provide accurate timing control over the beacons).
http://nordicsemiconductor.github.io/nRF51-multi-role-conn-o....
However it is really a waste of energy to send 2 types of beacon packets when one should suffice. However it is technically possible.
2 weeks doesn't seem like that long to persist with a major change like swapping from sitting all day to standing. Would be interesting to hear from someone who persisted with it for longer to see if they were able to adjust fully. I have a desk that is adjustable from sitting to standing and enjoy it as it lets me work longer without my back annoying me.
In regards to the 135 degree suggestion, I've found this doesn't work well for me, my lower back hurts, and also it encourages me to stick my chin forward which puts pressure on your neck. Could be a result of body shape or specifics of my setup though.
One more data point: Made the switch about two years ago here. At the time I was already fairly athletic, with normal BMI and in my mid twenties.
The first two weeks were incredibly difficult. After that you could feel the adaption kicking in, and by about a month I was able to stand for six hours at a time - punctuated by the usual trips to the kitchen and toilet several times per day of course.
Forget getting into the zone in this time. Compared with my peers, I would say I'm fast to adapt physically to new 'stresses' (from weight training and running in my experience), so I would judge this to be towards the 'best case' end of the scale.
Definitely agree that the author of this post threw in the towel too early. Standing for a full day is no mean feat. You wouldn't expect to run a marathon after two weeks of training having never run before.
I haven't tried a standing desk for programming yet (it's on my todo-list).
But I did have a summer job as a student where I was standing in front of a computer all day, registering incoming packages in a warehouse.
My feet hurt for the first few days, but after some experimentation with different footwear (I ended up with a pair of orthopedic sandals as the most comfortable), a soft mat to stand on, and a 5-10 minute break each hour, I had no issues after the first couple of weeks.
I'm pretty sure that moving is better than either standing or sitting. Since walking around isn't very compatible with working on a PC, I expect that an adjustable desk is pretty much the best we can do. Along with switching between standing and sitting, frequent breaks, and suitable footwear.
I bought a motorized adjustable standing desk. I don't stand the same amount of time each day, but typically at least two hours, and no more than about 6. I eased into standing gradually. When I first got it, I only had it "up" for maybe half an hour at a time.
I also don't strictly stand still. I'm always moving around a bit, even if it's just from one side of the desk to the other (it's a Geekdesk Max with a large (78.75" wide) desktop).
Back when I got a standing desk two years ago, it took me about two weeks to adjust, standing about 5 hr a day. It was mostly my feet that started to hurt back then, and I don't have a particularly strong back or good posture.
Nowadays I'm regularly on my feet for about 10 hours a day and just dont think about it that much. I do often walk around the office and constantly shift my weight around, which helps.
It took me two months to get used to my desk. Still, I was only able to work for 6 hours in a day when I used it. I spent a lot of time in the shop, it was where all my friends were and we would hang out there, so it wasn't uncommon to be there for 12-14 hours. I used a stool, or got away from my desk and did something else.
I agree with you about the neck for the 135 degree thing.
Really interesting article, thanks for writing it. I'd like to hear a bit more about the reasoning for the whole company swap, what problems you were having with C#/Microsoft stack. The impression I got was that you tried out something new for a small project, liked it and liked the idea of OSS in general and then started doing everything in that way, is that all there was to it? What other factors came into the decision on a whole?
I found the article very interesting as well but honestly it reads like a nightmare.
Company heavily invested in X. New CTO comes on board, gives the technology stack a "hard look" which is often a euphemism of, "I wouldn't have chosen that technology, so you must change." Large portion of the existing developers leave, new developers (including OP) come in. New developers base technology decisions on what's best for their career, not necessarily what's in the best interests of the company.
After all, in the Why Scala section they plainly state they knew little of Scala and there's a large section about what languages are hiring.
And as you said, if there is time spent on what made them decide to switch away from the Microsoft stack, it is buried to the point I couldn't find it in two read-throughs of the very long article.
Thats how it read to me too. Except I translated the CTO's "hard look" as "what big thing can I change to show I'm in charge."
Irrespective of the merits of the technology [1], if hiring a new CTO results in a lot of the existing development staff leaving then something is very wrong.
[1] I work on the .net stack, but I've tried Scala and think its a great language.
I'm sorry this is how the article came across to you. Given similar sentiments from others on this thread I'll see if I can amend it to make it more clear.
When our CTO came onboard I meant to say that he gave a hard look at our development process, not so much the technology stack itself. I agree it's confusing since the post is about Technology Change and I'm probably confusing the point further by mentioning both the earlier process transition when our CTO came onboard and then the later Scala technology change.
Thanks for your feedback.
EDIT: I've updated my post to elaborate on why a new CTO was brought into the organization.
Why not change dev methodologies while adopting F# to have a proper modern language? Seems like it'd make migration a far easier task, if you don't really need all of Scala's type system.
.NET culture is not F/OSS culture. Different personalities and types of people in those camps. Different expectations of capability. When you are looking to hire non-Blub programmers, it's a lot easier to find it in F/OSS-land.
F/OSS tooling has a big priority on interop with each other. MS tooling has a big priority on interop with MS (and companies that MS has contracts with or has strategic EEE priorities on). Having a broader base of tools to use is a big deal.
F/OSS development progress can be monitored and input can be given (and patches can be sent in). This is in contrast to the proprietary approach where you pretty much have to take what you're given, and input is limited (depending on company). So it's easier to manage church and breakage risk in F/OSS.
Full-size enterprise MS licenses are not cheap. The numbers I've heard thrown around are big. And it seems that MS tooling is focused on vertical scaling, so your HW costs start looking very large as you stack your enterprise memory & HA storage systems into the box. This is opposed to "el cheapo" redundant pizzaboxes. So you start incurring a particular kind of expensive cost.
All of these are reasons I think F/OSS development is a better place to be, to hire from, and to want to go to. None of those reasons were given in the article, so we are left with speculation - was this just the CTO throwing his weight around? was this an attempt to move to a more mentally flexible organization? was this an attempt to cut costs?
"hire non-Blub programmers, it's a lot easier to find it in F/OSS-land" - I am not sure that's the case, everyone seems to be crazy about Python, Ruby and JS.
Can you elaborate on this? I'm a new developer and would be interested in this perspective. If they have a new, energized staff that is shipping software on time and have old, untouched software that still works and communicates with the new software, what is the problem with that?
Looks like many agree with you, so I'm really curious about what problems arise long-term from decisions like that.
I mean...our legacy code is in BASIC...but if they told me I needed to maintain the BASIC programs, I would probably quit.
I don't see having some of the old-school developers leaving the company and being replaced by potentially better talent as a bad thing. One signal for me is that I hire smart people because technology changes. It's a red flag for me when people stop learning or lose the desire to add to their tool belt. Some people can't adapt.
But, hey, the world still needs Cobol programers, so...
With all due respect, you obviously know nothing about the Microsoft stack. These people were not using VB6. How do I know? From the article:
new projects chose a base technology stack of C#, ASP.NET MVC
ASP.NET MVC is not an "old-school" framework. It was first released in 2009!! That's four years newer than Ruby on Rails. It's ridiculously actively developed as well as being open source. It's currently in version 5 which was released October 17, 2013 which was... OMG 8 days ago.
I continue to be shocked at how little most HN developers know about the Microsoft stack and how much innovative work has been done since they last looked at it in 1998.
Ha, I worked a lot with ASP.NET MVC 2 & 3! By old-school, I was referring more to the lockin of the MSFT stack than the specificity of a particular library.
(When we moved over to a Python-based solution, we ported from MVC 3/SqlLinq/MS SQL Sever stack)
EDIT: Oh, and were had a lot of good stuff going on using ServiceStack....loved that set of libraries.
Changing for change's sake is probably much worse than sticking with something that works.
Chasing shiny things is great if that's your goal. But if your goal is to build great product, then focusing on that should be the goal. There's still a lot of great product written in C, Obj-C, C++, and Lisp -- all rather "dull" languages compared to the shiny new stuff.
Also that sentence has a strong implication that new developers are smarter than the old ones. Just because they choose one technology over another. I am personally well aware of Scala features, yet I choose C#.
Yes, I also read it as the other responders to you read it. Losing your staff, probably spending more on talent (you usually, not always, have to pay more to replace somebody), losing tons of institutional knowledge, basically having to rewrite everything from scratch (I find it interesting how on HN we simultaneously laud moving to CoolTech2000 and quote Joel on never rewriting existing software) switching development to something new that no one has experience with - well, those all have huge and long lasting costs.
Against that, we weren't given a reason for the change. Maybe he was being nice and not exposing how things were. I'm certainly aware of dysfunctional teams that really need everything fixed, and there is little to do but wield the ax and get it done. But it is a heck of a gamble. These "old timers" - perhaps they were cranking out pretty good code at a good rate, on a stable system they understood, on time and budget, and so on, and had somebody come in, tell them they aren't buzz word compliant, and enforce things on them that neither solve problems that they have nor really offers much of an advantage. Or, perhaps they were dinosaurs that took 3 months of arguments between 5 committees to decide whether to label a button "reply" or "send". I dunno.
I've seen it both ways. I had a programmer react to my use of python as "oh, that silly little language". Everything must be written in C and reinvented by him. Not a very useful attitude. OTOH, if I was to storm around and argue that our existing, well working c code should be converted to Scala for no particular reason, I'm being the unhelpful one.
tl;dr: I didn't see anything in the article that made me think the existing team was doing it 'wrong' to incur such risk and costs. I don't much care if they are successful - the risk stands out like a sore thumb. We eviscerate the bankers that bet the company for their quarterly bonus by pursuing high risk, high reward strategies, and say "cool" when somebody throws out their team, source code, and institutional knowledge in favor of a cool new language and buzzwordy development process.
I don't think they rewrote everything, though, did they? I read it that they were building up new stuff in this manner and they they were trying to move over to a SOA-style architecture, which it sounded like they didn't have with some old stuff.
I highly doubt they're just throwing all their products away.
As a C# developer I always find the problem with C# is the lack of any Darwinean process in MS libs. In a platform with a stronger open-source community, libraries battle it out in the marketplace of ideas and users and generally the solid ones rise to the top.
In .NET, MS provides everything, and the OSS counterparts are second-fiddle to the blessed libs. This is a problem since it stifles the OSS community trying to compete with first-party product... and while MS has generally competent coders and products, sometimes they make mistakes that are agonizing pain-points... and the MS obsession with "no breaking changes" means that those pain-points will never be fixed.
No MS mistake is ever fixed. It is replaced with a new library with a whole new week-long learning-curve and its own foibles and mistakes, which will, in turn, never be fixed.
I'm a C# dev too and I agree with you on the lack of "Darwinean selection". Definitely a downside of working on the Microsoft stack. Some of the great innovations coming out of the FOSS community seem to take a long time to reach us.
On the other hand, we miss a lot of the churn caused by people chasing after the latest js library, which also seems to be a big preoccupation of the FOSS community. If you're building software that has to last for years then stability of the underlying platform and having fewer ways to do something can be an advantage.
> On the other hand, we miss a lot of the churn caused by people chasing after the latest js library, which also seems to be a big preoccupation of the FOSS community. If you're building software that has to last for years then stability of the underlying platform and having fewer ways to do something can be an advantage.
Don't make me figure out how many database access approaches there are in stock .NET. :-)
More seriously, JS devs seem to have a thing for reinventing each others wheels - not just once, but tens of times (hyberbole). I really don't see that behavior in other communities by and large. The worst I've seen elsewhere is 3 similar Python libs
I dig appreciate the stability argument though. Which is why I'm a Common Lisp fan; its a standardized and mostly extensible language.
"Don't make me figure out how many database access approaches there are in stock .NET. :-)" - one high-level using Entity Framework, one low-level using ADO.NET. Non-stock options are plenty.
I disagree with Pxtl overall, but there are some high profile examples like Microsoft's Entity Framework coming from way behind and eventually overshadowing established open source ORMs like NHibernate.
On the other hand, creating a new ASP.NET MVC project with the official Microsoft template that ships with Visual Studio automatically pulls in open source libraries/frameworks like jQuery, Bootstrap, and Json.NET, not Microsoft-reinvented versions of those things.
In the beginning there wasn't an initiative to migrate away from .NET. Management encouraged us to try new technologies all time and the BeetleJuice spike seemed to me like a good opportunity to try something new given its simplistic requirements.
From an organizational perspective, there was some discord about how expensive our Microsoft infrastructure was and how poorly it scaled. I won't blame Microsoft for all our scaling problems, as a lot of it had to do with our legacy architecture, but licensing fees were a legitimate concern. Management didn't have any clearly defined goals to move away from Microsoft, but when we started using Scala, Mongo, and other open source projects they took the opportunity to make the case for more migration of our infrastructure. This new direction was officially announced as part of our CTO's Technical Strategy message to the dev department (included in my post).
