The Rise And Fall Of The Full Stack Developer | TechCrunch

SOURCE Techcrunch:



It seems as though everyone in tech today is infatuated with the full-stack developer. Full stack may have been possible in the Web 2.0 era, but a new generation of startups is emerging, pushing the limits of virtually all areas of software. From machine intelligence to predictive push computing to data analytics to mobile/wearable and more, it’s becoming virtually impossible for a single developer to program across the modern full stack.



When I first started programming computers as a kid in the pre-mobile, pre-web late 1970s/early 1980s, a single person typically wrote a complete software program from start to finish, and there weren’t many other layers of software between the programmer and the hardware. Using assembly language was the norm for programmers trying to squeeze more performance and space out of machines with 8-bit processors and very limited memory.



Programming applications quickly evolved into a team sport with the advent of client/server computing in the late 1980s and early 1990s, and the wave of Internet computing in the late 1990s and early 2000s. Each facet of new technology was so complex that a specialist was often required, sometimes one for different tiers (e.g. front-ends, databases, application servers, etc.) Managing a business website became a specialty that included operating networking equipment, such as routers and load balancers, tweaking Java virtual machines, and using various database indexing mechanisms.



By the mid-2000s, creating virtually anything — from simple websites to next-generation SaaS services — became prohibitively expensive. The rising expense was directly correlated to the overhead of numerous individuals from the various tiers communicating (and often miscommunicating) with each other, and changes in one tier cascading into other tiers and into deployment parameters. As Marc Andreessen pointed out in a recent tweet storm about burn rates, “More people multiplies communication overhead exponentially, slows everything down.”



Conversely, the technology to create the new generation of Web 2.0 sites became increasingly streamlined and simplified. Programmers switched from using the more complicated enterprise Java stack and databases such as Oracle to the more straightforward LAMP stack (Linux, Apache, MySQL, PHP/Python/Perl). New languages and frameworks such as Django and Ruby on Rails automated the layer between the website and the database. Front-end frameworks such as jQuery helped abstract all of the intricacies between different browsers. Cloud services such as Amazon Web Services simplified deployment and provided turnkey networking.



By the late 2000s, it became possible for many programmers to deliver a complete consumer or SaaS site, including a dynamic web client, server-side business logic, a scalable database, deployment, and operational support. This new breed of full-stack developer could run circles around teams of programmers attempting the same task. When projects scaled up, adding more full-stack programmers allowed a single person to add a single feature across all the tiers of an application, which accelerated feature delivery over the communication overhead of having different people own the feature in each tier.

If you’re building a website on the full stack illustrated above, find full-stack developers who can effectively wear these hats. But these days — and call me crazy — I’d consider this a less-than-full-stack. Here’s a fuller full stack:

I’d wager that there are zero individuals with advanced-level knowledge in each of these areas that would be capable of single-handedly delivering this next generation kind of application. Just keeping up with the advancements and new programming interfaces in each category is almost a full-time job.



We are in the midst of a rapid shift to more complicated technologies that, as in days gone by, require experts at each tier. Developing excellent iOS and Android applications requires experts in those platforms that understand the intricacies. Operationally, tending to new object databases such as Mongo requires constant attention and tweaking. Running an application on cloud services such as Amazon requires knowing the ins-and-outs of its various services and expertise on how to failover across regions. Even the venerable web front-end has evolved into CSS4, JSON and JavaScript MVC frameworks, such as Angular.js and Backbone.js.



In this brave new world, it is critical to have at least one person with at least a functional understanding of each of the composite parts who is also capable of connecting various tiers and working with each expert so that a feature can actually be delivered. In a way, these tier-connecting, bridge-building software architects — who are likely experts in only one or a couple of tiers — are less full stack developer and much more full stack integrator.



Rest in peace, full stack developers. Welcome, full stack integrators, in addition to engineers with deep technical skills in particular areas. It’s a fascinating world of software out there and we need you more than ever.

Mocks Aren't Stubs

Mocks Aren't Stubs:

The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing.

Final Thoughts

As interest in unit testing, the xunit frameworks and Test Driven Development has grown, more and more people are running into mock objects. A lot of the time people learn a bit about the mock object frameworks, without fully understanding the mockist/classical divide that underpins them. Whichever side of that divide you lean on, I think it's useful to understand this difference in views. While you don't have to be a mockist to find the mock frameworks handy, it is useful to understand the thinking that guides many of the design decisions of the software.

The purpose of this article was, and is, to point out these differences and to lay out the trade-offs between them. There is more to mockist thinking than I've had time to go into, particularly its consequences on design style. I hope that in the next few years we'll see more written on this and that will deepen our understanding of the fascinating consequences of writing tests before the code.

Chris Wong's Development Blog: JmsTemplate is not evil

Chris Wong's Development Blog: JmsTemplate is not evil: A while back, I watched a presentation on JMS messaging where the presenter (Mark Richards) declared that Spring’s JmsTemplate is “evil,” an...

Java Spring bean with private constructor - Stack Overflow

Java Spring bean with private constructor - Stack Overflow:

Spring bean with private constructor

up vote4down votefavorite 1	Is possible in Spring that class for bean doesn't have public constructor but only private ? Will this private constructor invoked when bean is created? Thanks. java spring constructor javabeans private share|improve this question asked Aug 31 '11 at 8:36 user710818 2,47911340 77% accept rate
	3   How about giving it a try and then posting the results? – dm3 Aug 31 '11 at 8:38 It is difficult - I don't have all source. – user710818 Aug 31 '11 at 8:40 feedback

3 Answers

activeoldestvotes

up vote7down voteaccepted

Yes, Spring can invoke private constructors. If it finds a constructor with the right arguments, regardless of visibility, it will use reflection to set its constructor to be accessible. share|improve this answer edited Aug 31 '11 at 9:13 answered Aug 31 '11 at 8:48 Kevin Stembridge 2,271720

Could you please give me the reference to docs? Constructor has parameters, and in xml file to this arguments assigned values. – user710818 Aug 31 '11 at 8:52 you mean if a bean has specifically something like private bean() { ... } spring can invoke that? How is that possible, that defies the whole purpose of "private". – Ashkan Aryan Aug 31 '11 at 8:56 Sorry, I'm probably wrong about it only being no-arg constructors. I'm just going by what I've noticed on my own projects. I can't say I've ever seen it in the Spring documentation anywhere. But this is the javadoc for the class that is responsible for doing the instantiation. static.springsource.org/spring/docs/3.0.x/javadoc-api/org/…...) – Kevin Stembridge Aug 31 '11 at 9:01 4   @Ashkan It is possible using reflection. In particular, the Spring BeanUtils class uses a class called ReflectionUtils to make the constructor accessible. See javadocs for Constructor.setAccessible(). – Kevin Stembridge Aug 31 '11 at 9:03 @Kevin Stembridge you are correct, it is possible using Reflection. – Ashkan Aryan Aug 31 '11 at 9:07 show 2 more comments feedback

up vote2down vote

You can always use a factory method to create beans rather than relying on a default constructor, fromThe IoC container: Instantiation using an instance factory method: <!-- the factory bean, which contains a method called createInstance() --> <bean id="serviceLocator" class="com.foo.DefaultServiceLocator"> <!-- inject any dependencies required by this locator bean --> </bean> <!-- the bean to be created via the factory bean --> <bean id="exampleBean" factory-bean="serviceLocator" factory-method="createInstance"/> This has the advantage that you can use non-default constructors for your bean, and the dependencies for the factory method bean can be injected as well. share|improve this answer edited Aug 31 '11 at 9:08 answered Aug 31 '11 at 8:51 Matthew Farwell 20.9k52964

interesting, but I cannot find factory. May be exists another way? – user710818 Aug 31 '11 at 9:08 1   You can't find factory? I don't understand what you are saying. – Matthew Farwell Aug 31 '11 at 9:09 @Matthew: He appears to be retrofitting Spring around some fugly third-party code. That's just bound to be messy. – Donal Fellows Aug 31 '11 at 9:29 1   @Donal, no I didn't understand what he said in the comment. – Matthew Farwell Aug 31 '11 at 9:52

'via Blog this'

Java 7 Webcast

Java 7 Webcast:

JAVA 7 TECHNICAL BREAKOUTS				EVENT HOSTS
	See the presentations for all technical breakouts below: Making Heads and Tails of Project Coin, Small Language Changes in JDK 7 (Presentation/PDF) Divide and Conquer Parallelism with the Fork/Join Framework (Presentation/PDF) The New File System API in JDK 7 (Presentation/PDF) A Renaissance VM: One Platform, Many Languages (Presentation/PDF)

'via Blog this'