Part 2 of the Blog Series: Cloudy with a Chance of VMs: Scaling Up & Out with Azure explains how to configure an Azure Load Balancer and compares Manual VM scaling to Auto-Scaling via Azure Scale Sets.
Backend Pool configuration
Cloud Computing shines in a cost-benefit analysis; virtually unlimited resources are available at a moment’s notice, and resources must only be paid for if and when they are needed. Unlike dedicated servers, Cloud-based resources scale quickly & automatically to respond to peak loads. They can also provide fault tolerance via replication both within and between data centers. (more…)
Me: . . . Okay, so I understand a little bit about your project goals and how they fit in with your business needs. . . Can you tell me, if you know, what technologies your current application was built with?
Client: Um. . . I’ve heard some of the folks say “PHP”. . . does that make sense?
Me: Sure does. Any idea what version of PHP and which framework it might be leveraging?
Client: Oooh, I don’t know. . . I can get that for you though. . .
Me: That’s okay. How about this: How old is the application and when is the last time you did an update?
Client: Well, we developed it in 2007 and we had a person who worked on it for just a couple years after that but they aren’t here anymore. . .
Software development has moved through several “ages” as both technical innovation and the cultural evolution driven by those technical innovations has moved from the early adopters through the late adopters and permeated our expectations of what technology is.(more…)
I still run into a lot of companies that have the expectation that software development can be done on a fixed-price basis. They’re either still used to waterfall management style, or dealing with goods vendors, or, maybe a few are still running into software developers willing to work on a fixed-price basis.
On this blog, we’ve talked about the dangers inherent in fixed-price development services. How companies willing to offer an FPB will triple their hourly rate for change requests in order to make up the margin they already know exists between what they think the project will cost, and what it actually will end up costing. How every project, no matter how well planned out, rarely looks the same at the finish as it did at the start. How the number of unknowns at the start of a development project could fill a dump truck. What we haven’t talked much about is when it is reasonable to ask for, or expect, a fixed price. (more…)
When Art & Logic started doing business in 1991, we were a fully remote company that pre-dated the availability of the consumer internet; by the time I joined up in 1997 that transition had happened. My initial internet connection when I started here saw me upgrade from a dialup connection to a local ISP over a 56Kb/s modem to a pair of bonded ISDN lines that gave me a screaming 128 Kb/s connection to the A&L servers and my co-workers.
As the consumer internet exploded, our project mix followed the same transition that the rest of the world did — we went from 100% of our projects being standalone desktop applications running natively on Windows or macOS, to a few web projects (including a ton of embedded web projects — in 2017 you expect to be able to configure networked hardware by pointing a web browser at it, but in the late 90s that was the New Frontier) to our current mix that’s largely web and mobile with some interesting desktop apps tagging along as well.
We, along with every one of the clients that we’ve developed projects for in that period, have depended on strong net neutrality to enable our innovation — once your service is on the internet, your traffic is on the same footing as everyone else’s. As Gertrude might say today, a bit is a bit is a bit.
Recently, the FCC has proposed rule changes that have the potential to turn this all upside down — here’s a bit of background from meta.stackeschange.com :
Back in 2014, the United States Federal Communication Commission, in response to numerous complaints and concerns, implemented a set of rules that prohibit Internet Service Providers from blocking specific content providers or charging them for access to their networks. Essentially, a set of rules that prevent an ISP from double-dipping on service they’re already being paid for, or blocking access to specific websites just for the hell of it.
In order to do this, they had to change how ISPs were classified, moving them from a “Title I” classification to “Title II” – more or less the same framework for regulation that’s been in place for phone companies for decades, establishing them as a so-called “common carrier” – that is to say, one which may not discriminate between customers. If you already assumed that this is how the Internet worked, you’re not alone; however, due to how they were classified previously the FCC had been unable to enforce rules that would ensure that traffic over the Internet would continue be allowed to work as, well, traffic over the Internet was expected to work.
(also scroll down for the answers on the rest of that page for more discussion and links on the topic than you probably have time for today).
The group Fight for the Future has declared today, 12 July 2017, as a day of action, for “regular friendly Internet users like you to submit your comments and concerns to the FCC about their plans to do away with net neutrality.”
If you’re in the US and would like to participate, you can:
At WWDC earlier this month Apple previewed ARKit – it’s initial foray into Augmented Reality or AR. Alongside the intro session at WWDC they published Understanding Augmented Reality which provides a nice overview of how ARKit works, best practices, and its limitations.
Following WWDC the development community has put together a number of great demos that highlight the possibilities and potential of ARKit and the Made with ARKit (@madewithARKit) site has been chronicling some of the best of these.
Icy wind blew the pages of the young man’s book from beneath his near-frozen fingers. His tattered gloves helped little. He huddled in an alley finding what warmth he could behind a bakery. The scent of baking bread made his mouth water but he dared not spend the few coins he had. His family needed every penny he earned as a newsboy to survive. He returned to the book — a law book — the hundredth he had studied cover to cover since coming to America, a poor Russian child who spoke no English. In a few short minutes, he would head back out onto the street and cry “paper,” just as he had every day since his 10th birthday. But for now, he needed to focus on his studies, no matter how cold he was. (more…)
A couple of us were among the 100,000+ attendees at the recent NAB Show in April. If you’ve never been to the show, it would be kind of tricky to describe it fully since it’s rather broad and all-encompassing when it comes to media and digital content. The National Association of Broadcasters describes it as follows:
[NAB Show is] the world’s largest convention encompassing The M.E.T. Effect, the convergence of media, entertainment and technology. With 103,000 attendees from 166 countries and 1,700+ exhibitors, NAB Show is the ultimate marketplace for solutions that transcend traditional broadcasting and embrace content delivery to new screens in new ways. From creation to consumption, across multiple platforms and countless nationalities, NAB Show is where global visionaries convene to bring content to life in new and exciting ways. (more…)
The first thing I learned by starting a business is that it’s best just to do something. If you have an idea for a business, and you love the idea, and you believe it to be a good idea, then just run with it. If it doesn’t turn out great, or even if it fails, learn from your mistakes, and do it better next time. If you sit around just thinking about how to do something perfectly, you’ll never do anything. So rather than sitting around thinking about how to write the perfect article about this, I’m just going to jump in and start writing!
Here then is a list, starting with the second thing that I learned by starting a business.(more…)
In my last post I took a closer look at how the Apollo iOS GraphQL client executes queries and what the resulting JSON looks like. In this post I’m going to focus on how the JSON is parsed and converted to the native Swift types generated by the apollo-codegen tool and also look at how the Apollo iOS client caches results. (more…)
In my last post I took a look at using the Apollo iOS GraphQL client framework to access a GraphQL backend running on the Graphcool GraphQL mBaaS. Shortly afterwards Brandur Leach, an API engineer at Stripe posted “Is GraphQL the Next Frontier for Web APIs?“. In his post Brandur gives a good overview of the current API development space, compares GraphQL to other technologies, and ultimately puts his support behind GraphQL. The follow-on discussion on Hacker News is a bit mixed, with some comments in support of GraphQL along with a few dismissing it. Some advocate support for both REST-like and GraphQL APIs, given that with a sensibly designed backend, support for both is possible with too much additional work. Stripe has a popular REST API that is used by a lot of developers, given Brandur’s opinions, it will be interesting to see if they take this hybrid approach and start offering a GraphQL interface as well.
Regardless of whether GraphQL will gain more traction compared to other approaches or not, I wanted to dive a bit deeper into the client side of things and get a better understanding of how the Apollo iOS framework and apollo-codegen tool work. (more…)