Coffee Talk: Java, News, Stories and Opinions

Page 1 of 1412345...10...Last »

April 19, 2017  6:15 PM

Java 9 will finally give the term ‘deprecated’ meaning

cameronmcnz Cameron McKenzie Profile: cameronmcnz

I’m not sure if I’m alone on this opinion, but it sure seems to me that the deprecation of the finalize method has been given way too much press. I can’t recall this much fervor over method deprecation since they blacklisted the java.util.Date() constructor and told everyone to start using a GregorianCalendar instead.

Java methods deprecated meaning

One does not simply stop calling deprecated methods

Giving the term ‘deprecated’ meaning

Whenever deprecated Java methods become news, I always like to troll the language gods over the fact that even though methods get deprecated, the underlying code never actually gets removed from the API, and as a result, lazy developers just keep using it, deprecation warnings be damned.

Previous rantings from TheServerSide about deprecated meaning nothing 

In a recent blog post, entitled Deprecation of Object.finalize(), Oracle Technical Staff Principal Stuart Marks set the record straight not only on what was being deprecated in Java 9, but which deprecated methods were actually being pruned from the API as well. Here’s the pertinent excerpt from his article:

The following six APIs were deprecated in Java SE 8, and they have been removed from Java SE 9:

  1. java.util.jar.Pack200.Packer.addPropertyChangeListener
  2. java.util.jar.Pack200.Unpacker.addPropertyChangeListener
  3. java.util.logging.LogManager.addPropertyChangeListener
  4. java.util.jar.Pack200.Packer.removePropertyChangeListener
  5. java.util.jar.Pack200.Unpacker.removePropertyChangeListener
  6. java.util.logging.LogManager.removePropertyChangeListener

In addition, in Java SE 9, about 20 methods and six modules have been deprecated with forRemoval=true, indicating our intent to remove them from the next major Java SE release. Some of the classes and methods to be removed include:

  • java.lang.Compiler
  • Thread.destroy
  • System.runFinalizersOnExit
  • Thread.stop(Throwable)

The modules deprecated for removal are the following:

  1. java.activation
  2. java.corba
  3. java.transaction
  4. java.xml.bind

So yes, we are getting serious about removing stuff!

Deprecated value != deprecated meaning

So I guess that will shut me up for a while. They’re getting around to pruning the API and getting rid of the deprecated methods. All I ask is that they don’t prune away that deprecated java.util.Date constructor. I’m still writing code that uses it.

You can follow Stuart Marks on Twitter: @stuartmarks
You can follow me as well: @cameronmcnz

April 14, 2017  1:53 PM

How Disney organized for a DevOps transition

George Lawton Profile: George Lawton

Conversations about architecting the enterprise for agility often start with a consideration of new technologies. However, this only works when enterprises processes and policies that support them are in place, said Jason Cox, director of system engineering at The Walt Disney Company.

One of the tragedies of the traditional notion of agility lies in the drive for speed without processes that nourish the developers and ops people that support them, said Cox. When Cox joined the group they were in non-stop firefighting mode. They began glorifying the “heroes,” that worked marathon hours without sleep. But over time, these heroes burnt out. The problem was that development engineers looked down on the operations team. Walt Disney management renamed the operations team members ‘System Engineers.’

“This had a profound effect,” said Cox. The developers saw these people as fellow engineers and invited them to discussions about changes to software and infrastructure on equal footing. “The developers were constructing the software together with the systems engineering teams.” This eventually led to collapsing the teams together, which helped to continually improve the applications and architecture.

Architect a common core with distributed engineering

In 2011, they began a more aggressive pursuit of a DevOps strategy. This was as much about rethinking about the communication infrastructure and organization hierarchy as the technology.

This lead to a transition from functional teams to a matrix team organizational model. In the functional team model, developers and infrastructure were tasked with supporting one line of business. In the matrix team model, Walt Disney established a core DevOps team for providing IT services to its four main business groups.

This team is responsible for providing core IT services, and also embeds managers, staff, and engineers across the different Walt Disney Business units. “The benefit is that because we have a centralized connection point, we can be a cross business conduit,” said Cox. “We can take new tools, processes, and lessons learned and share those across the different segments because of the model we have adopted through this embedded matrix organization.”

April 13, 2017  1:24 PM

Architecting cloud systems and the human side of DevOps deployment

George Lawton Profile: George Lawton

According to Adrian Cockcroft, VP of cloud architecture at AWS, one of the biggest challenges in architecting cloud systems lies in architecting the people side of things. Along with the work he does at Amazon, Cockcroft also played a key role in architecting Netflix’s cloud strategy. After Netflix’s rise to prominence, he would often give talks at CIO roundtables who invariably asked where he got all of the superstar engineers. “Well we hired them all from you,” he would respond.

Over the years, Cockcroft pondered what made Netflix so attractive to top talent. One element was Netflix’s very progressive open source program, which allowed developers to take pride by sharing with the larger community of developers. This also runs the danger of attracting recruiters who could lure away programmers.

Compensation and be financial or prestige

Netflix established a very aggressive compensation schedule to address this danger. Each year programmers are rated and compensation is based on what it would cost to hire someone with similar talents. This might not fly in many enterprises with a focus on percentage increases. “I don’t know of any other company that does this on an annual basis,” said Cockcroft.

Another good practice lies in establishing status for important talent by curating a circle of “distinguished engineers” or “fellows.” Once this circle is large enough, members can nominate others into this groups which becomes a sort of elite club. The way to enter this group is to provide value to other distinguished engineers. Over time these distinguished engineers get to know each other as a group, which builds cohesion and loyalty.

April 11, 2017  8:57 PM

2017: A year for women being bold with change in technology

Daisy.McCarty Profile: Daisy.McCarty

This year, the theme for International Women’s Day was “Be Bold for Change”. To kick off my series on women in technology, I made a point of attending a local celebration hosted by Intuit. All the tickets had been snapped up very quickly, but I took a chance and asked for a press pass from the event organizer who kindly obliged. I figured I had to be bold myself if I wanted to meet some great women in the technology space. It was a smart move.

After a harrowing drive through rush hour traffic, I snagged my name badge with minutes to spare before the first speaker took the podium. Upon arrival, I noticed one thing that immediately set this event apart from typical tech-focused events I had attended in the past. Even with more than a hundred people in the room and wine flowing freely, it was still possible to carry on a conversation without shouting. And when it came time for the attendees to take their seats and the program to begin, this feat was accomplished with a simple request. It was a cooperative and considerate start to the evening. The room was filled with a sense of purpose. These women were here to listen and learn.

Event host Intuit sets the pace for diversity in technology

CeCe Morken, Executive VP and General Manager of Intuit’s ProConnect Group, broke the ice with a short introduction about what inclusion means to her organization. “One of the things that we’ve learned is that innovation can thrive when you have a workforce that is made up of different life experiences and you have a culture that supports those experiences and allows diverse and new ideas to rise to the top.” I learned that this company is well-known for having a better gender balance than most technology firms. About one third of the tech roles at Intuit are filled by women, and the leadership at the CEO and executive level stands at about forty percent. Even with these impressive stats compared to competitors, CeCe admitted that the company still has room to improve. With a woman leading this change in the role of Chief Diversity Officer, I can well believe that the company will continue moving toward its goals.

“I often equate boldness with risk. Because if you don’t take risk, you aren’t putting yourself out there.”
-Elisa Miller, CA Technologies

In the meantime, the organization is leveraging its diverse workforce to take on some tough challenges. “One of the things being bold means to us is finding a really big, important problem. Whenever we talk about that we say, ‘Fall in love with the problem, not the solution.’ As an example of a huge problem, fifty percent of small businesses don’t survive five years. These businesses are the backbone of the economy globally, and they are built by our neighbors and friends.” Intuit has set a goal to cut the failure rate of small businesses by fifty percent in the next five years. It’s a grand challenge, but certainly a worthy one. With about thirty percent of small businesses world-wide owned by women, it’s one way to make a bold change that favors female success everywhere.

Women speak out on the importance of being bold

Like the rest of the attendees, I was impressed with the quality of the speakers selected for the panel. They represented entrepreneurial, academic, corporate, and executive backgrounds and decades of experience in technology. While each one delivered helpful answers to the moderator’s questions, I also noted the range of dispositions on display. From outgoing and energetic to thoughtful and concise, it was a perfect way to showcase that there isn’t a particular personality type that makes a woman more likely to succeed in a tough industry like technology. The one thing these ladies did have in common was persistence. Being bold was not just one big leap. It was the courage to take action over and over in the face of resistance, disagreement, and doubt.

Boldness follows excitement for avid problem solvers

After the first round of introductions and professional biographies, the speakers dove right into the question of what it means to be bold. The youngest panelist, Candy Bernhardt, Head of Design UX in Capital One’s auto lending division, took first crack at giving an answer. “As one example, I was put in a situation where I was driving an innovation team to look for new, important challenges in the travel space. When I’d go find the biggest juiciest problem, I’d realize through feedback that as someone was describing a big, seemingly unsolvable problem, I would start smiling.” This unintentional habit apparently ruffled some feathers. I could imagine Candy’s cohorts pouring out their frustration and angst only to be met with a Cheshire grin. It must have been disconcerting.

According to Candy, she had some explaining to do. “I had to explain that I’m not smiling because I don’t think the problem is hard. I’m smiling because it is hard. There’s something that hasn’t been discovered or challenged and that got me excited. For me, being bold is about wanting to tackle those challenges and loving it.”

Seeking success is not for the faint of heart

Julie Hamrick, Founder and COO of Ignite Sales, told a personal story about putting everything on the line because she believed in herself. Hamrick’s quiet and calm demeanor opened up to reveal some steel beneath. “Sometimes boldness just means ignorance, stubbornness. Doing something because you think it’s the right thing to do or because the naysayers say no.” In building a company from the ground up, it meant going all in when it seemed to her friends like she might be buying deck chairs for the Titanic. “For me, it meant getting a second mortgage on my house when I just knew that the company could make it but we were out of cash.”

How do you know that it’s time to take bold action? It’s not always a choice. Sometimes, it’s a necessity. “There’s something inside you, a spark that says I’ve just got to do it.” For Julie, the gamble paid off. In the end, her company was, as she put it, ‘a fifteen year overnight success.’ There were certainly many other daring choices along the way, but this was a perfect example of what it meant to risk it all for the sake of crafting one’s own future in the tech sector. With plenty of other female entrepreneurs in the room, I could sense that this was a story that gave fresh drive to those who were set on taking the road less traveled.

Being a leader in technology is about setting the pace

After these tales of personal boldness, Mamie Jones, ProConnect Sr. VP of Product Development at Intuit, took a completely different approach to the topic. It was the collaborative view from the role of a leader who had been tasked many times with transforming technology groups. “For me the boldness is, number one, listening to the people within the organization. Two, summarizing what you are hearing, three, pulling people together to ask ‘Did we get it right and are these the things we need to go tackle?’”

According to Jones, once the challenge has been defined and the action steps lined up, it’s time to make it happen. This starts with an audacious statement. She referenced Kennedy’s declaration about going to the moon in the sixties as an example. It was no more than a dream when he made the promise, but everyone pulled together to make it a reality. It’s that boldness of vision that women like Jones bring to their technology teams. “I’ve found that when you put the grand challenge out and you’ve defined the problem, you can put a very bold declaration out there. And if you get out of the way and let people go, it is extraordinary what they will achieve.”

It struck me as Jones concluded her story that this approach to leadership is particularly well suited to the collaborative working style that comes naturally to so many women. It has the added benefit of being a leadership style that men can also recognize and respect. Great communication, courageous vision, and the ability to empower others to act: what could be a better combination?

Being bold means being true to yourself

Elisa Miller, a Design Transformation Coach for CA Technologies, concluded the evening with a story of being a sole survivor turned team champion within her organization. As a self-described ‘individual contributor’, Elisa swore never to be a manager. Although she was competent at leading others, she had no desire to do so. But she proved that even a single bold voice from the ranks can make a big difference in charting the course of an entire company.

“I often equate boldness with risk. Because if you don’t take risk, you aren’t putting yourself out there.” Those risks can make or break a career. Miller told the story of helping build a UX team of eight people under a senior manager. Six short months later (and several rungs up the ladder), a decision was made to lay off half the team. Apparently, the move was financially motivated and not about performance. The manager predicted that the team would dissolve as a result of this shattering blow, and that’s precisely what happened. Within short order, every single person on the team had quit—except for Elisa.

“I decided, now is the time for me to take a risk. I sat down with the woman who was now my boss and said, ‘We need to present to our new product officer why design is important.’” Elisa crafted the presentation, but her role wasn’t considered lofty enough to allow her direct access to the Chief Product Officer. Her manager made the pitch instead. Fortunately, the message about the reasons why the design team should have a seat at the table and finally be heard got through.

“I made it perfectly clear that I had the courage of my convictions. I didn’t tell anyone, but I made a private promise that if I did not see positive change in six months, I was going to quit.” Less than three months later, the Chief Product Officer announced his new organizational structure with a general manager of design reporting directly to him. Miller was offered the position. Of course, she declined. Her victory was already earned. Her parting words for the rapt crowd on International Women’s Day were succinct. “Take a risk. It’s scary. That’s exhilarating. Go for it!”

Top takeaways from the night

At the end of the evening, I had the opportunity to speak with many of the attendees. It was an excellent opportunity to get a feel for the chord the speakers had struck with their peers. We agreed that:

  • Persistence is the secret to success
  • It’s OK to have an unpopular viewpoint
  • You should never let someone tell you what you want to achieve is impossible
  • We are all in this together
  • Women helping one another in technology can make anything happen

We are all looking forward to the strides women will make in tech by next International Women’s Day!

April 11, 2017  8:42 PM

List of best books to learn R

GeorgeBailey Profile: GeorgeBailey

Best Books to Learn R

R is probably every data scientist’s preferred programming language
(besides Python and SAS) to build prototypes, visualize data, or run analyses on data sets. Many libraries, applications and techniques exist to explore data in R programming language. So here is our recommendation for the best Book to learn R and become a master of the technology.

a. A Handbook of programming with R by Garrett Grolemund

It is best suited for people new to R. This book teaches you to learn
how to load data, assemble and disassemble data objects, navigate R’s
environment system, write your own functions, and use all of R’s
programming tools. Here you will understand how to write functions &
loops in R, rather than just juggling with packages. The book language
is simple to understand and examples can be reproduced easily.

Best Books of R

b. The Art of R programming by Norman Matloff

This book teaches how to do software development with R, from basic
types and data structures to advanced topics. No statistical knowledge
is required, and your programming skills can range from hobbyist to pro.

Best Books of R

c. An Introduction To Statistical Learning With Applications in R by Trevor Hastie and Rob Tibshirani

Even if you’re a novice at machine learning and don’t know R, I’d
highly recommend reading this book from cover to cover, to gain both, a
theoretical and practical understanding of many important machine
learning and statistical techniques.

R best books

d. Learning RStudio For R Statistical Computing by Mark P.J.van der Loo

This book is different from the others in the list in the sense that
it teaches you how to use R on the popular IDE RStudio rather than on
the standard R software. The book is for R developers and analysts who
want to do R statistical development using RStudio functionality. So you
can Quickly and efficiently create and manage statistical analysis
projects, import data, develop R scripts, and generate reports and

R Best Books

e. Practical Data Science with R by Nina Zumel & John Mount

It focuses on data science methods and their applications in real
world. It’s different in itself. None of the books listed above, talks
about real world challenges in model building, model deployment, but it
does. The author focusses on establishing a connection between ML and
its impact on real world activities. It’s a must read for freshers who
are yet to enter analytics industry.

R Best Books

Read the complete article>>

April 11, 2017  8:41 PM

How to perform streaming transformation operations in Apache Spark.

VijaySharma Profile: VijaySharma

Through this Apache Spark
Transformation Operations tutorial, you will learn about various Apache
Spark streaming transformation operations with example being used by
Spark professionals for playing with Apache Spark
Streaming concepts. You will learn the Streaming operations like Spark
Map operation, flatmap operation, Spark filter operation, count
operation, Spark ReduceByKey operation, Spark CountByValue operation
with example and Spark UpdateStateByKey operation with example that will
help you in your Spark jobs.

Introduction to Apache Spark Streaming Transformation Operations

Before we start learning the various Streaming operations in Spark, let us revise Spark Streaming concepts.

Below are the various most common Streaming transformation functions being used in Spark industry:

a. map()

Map function in Spark passes each element of the source DStream through a function and returns a new DStream

Spark map() example

val conf = new SparkConf().setMaster("local[2]") .setAppName("MapOpTest")
val ssc = new StreamingContext(conf , Seconds(1))
val words = ssc.socketTextStream("localhost", 9999)
val ans = { word => ("hello" ,word ) }    // map hello with each line
ssc.start()    // Start the computation
ssc.awaitTermination()    // Wait for termination

b. flatMap()

FlatMap function in Spark is similar to Spark map function, but in
flatmap, input item can be mapped to 0 or more output items. This
creates difference between map and flatmap operations in spark.

Spark FlatMap Example

val lines = ssc.socketTextStream("localhost", 9999)
val words = lines.flatMap(_.split(" "))    // for each line it split the words by space
val pairs = => (word, 1))
val wordCounts = pairs.reduceByKey(_ + _)

c. filter()

Filter function in Apache Spark returns selects only those records of
the source DStream on which func returns true and returns a new DStream
of those records.

Spark Filter function example

val lines = ssc.socketTextStream("localhost", 9999)
val words = lines.flatMap(_.split(" "))
val output = words.filter { word => word.startsWith("s") }    // filter the words starts with letter“s”

d. reduceByKey(func, [numTasks])

When called on a DStream of (K, V) pairs, ReduceByKey function in
Spark returns a new DStream of (K, V) pairs where the values for each
key are aggregated using the given reduce function.

Spark reduceByKey example

val lines = ssc.socketTextStream("localhost", 9999)
val words = lines.flatMap(_.split(" "))
val pairs = => (word, 1))
val wordCounts = pairs.reduceByKey(_ + _)

Read the complete article>>

April 6, 2017  6:58 PM

From the JSF 2.3 release to the Amazon AWS outage, we’re taking shots at easy targets

cameronmcnz Cameron McKenzie Profile: cameronmcnz

Watching both the tech industry as well as mainstream media oversimplify the February 2017 Amazon S3 outage story annoyed me greatly. The annoyance transitioned into keystrokes, producing two opinion pieces on the topic, one of which evaluated the impact the outage would have on the faith users put into their service providers, while the second tried to filter out the Amazon noise and move past the manner in which the media greatly oversimplified the problem. Both articles garnered some interesting feedback on TSS, social media, and the TechTarget’s family of Search sites which aggressively tweeted the stories:

Was the Amazon S3 outage a Chernobyl even for AWS?
Stop repeating this fake news story: An input error did not cause the Amazon S3 outage

We’re not picking on Amazon

Some have asserted that I’ve been picking on Amazon. The fact is, a number of recently published features on TheServerSide have been picking on everyone, so it’s not like we’ve been singling them out.

Everyone loves picking on JSF. TheServerSide put up a feature article last week asserting that web UI frameworks should not be part of the Java EE specification. Some suggested that the article was just another pot shot at JSF, but it wasn’t. Taking JSF out of the Java EE spec would actually be good for JSF, and the article articulates why. At TheServerSide, we’re JSF advocates, and I’m excited about the future of JSF. Taking a look at what’s new in JSF 2.3 makes me believe that many of the little frustrations that aggravated developers have been addressed, and the future is bright for the Java based, web component framework.

We must remove web UI frameworks like JSR-371 and JSF from Java EE
What’s new in JSF 2.3? CDI alignment and integration with client-side technologies top the list

From deprecated Java methods to RESTful web development

Oracle’s inability to prune deprecated methods out of Java SE also came under fire, with a callback to an interview we did with Rod Johnson about a hundred years ago discussing how Spring makes method deprecation something developers should take seriously.

When will Oracle start purging Java deprecated methods from the spec?

The over-hyped DevOps trend also became a target, as did RESTful web development with XML and JSON. We even took a shot at every single development stack and framework that competes with Java EE, which is indeed a tall glass of water.

DevOps and Agile: Riding the magical unicorns of software development
My RESTful calls read JSON but write XML. Does that make me a bad person?
Forget software conglomerations. Java EE is best-of-breed enough. 

So perhaps we did pick on Amazon a little but, they weren’t the only victim of our scrutiny. If anyone was to suggest that Amazon was the only target TheServerSide’s opinion pieces were targeting, they’d be way off the mark.

You can follow Cameron McKenzie on Twitter: @cameronmcnz

March 29, 2017  1:08 AM

One does not simply ‘stop calling’ Java’s deprecated methods

cameronmcnz Cameron McKenzie Profile: cameronmcnz

They’re deprecating finalize.

That’s a pretty drastic move. Finalize is defined right there in the Object class, right at the top of the Java hierarchy, more exposed than a public variable. But the semantics of the finalize method are tied to the JVM’s infamous garbage collector. Nobody designing the API twenty years ago would have imagined that twenty years after declaring the finalize method, the garbage collector would still be thoroughly unpredictable in its trash collection patterns; if they did, they never would have coded it in the first place.

The finalize method must die, because banking on the JVM’s gc system, and subsequently tying functionality to the death of a POJO, is bytecode-based malevolence. So in a near future release, there will be a little @deprecated annotation placed on the finalized method. So what exactly does that mean? In the Java world, it means very little.

One does not simply stop calling deprecated Java methods

One does not simply stop calling deprecated Java methods

Hiding Java method deprecation problems

There are plenty of deprecated methods in Java, and there’s nothing stopping you from calling them. Sure, a yellow yield sign might appear in the line-number bar of your Eclipse or NetBeans IDE, warning you that you’re calling one of Java’s deprecated methods, but that’s about it. An easy way to address this issue is to go into the IDE’s preferences window and tell it not to report calls to deprecated methods. Just perform that quick change, and maybe do a rebuild, and all of the deprecated method warnings will go away.

Another approach is to decorate the the code you write with the @SuppressWarnings( “deprecation” ) annotation. That’s another simple way to make your deprecation problems disappear.

Java method deprecation problems solved

For those managing the Jenkins build, at the compiler level, you can use the -Xlint:all switch on the compiler to stop you from the seeing warnings about deprecated method calls during your Gradle or Maven builds. Really, there are a variety of approaches to dealing with deprecated methods; these are just some of the more common ones.

Of course, some might argue that the proper approach is to just stop calling deprecated methods. There may have been some impetus to do that ten or fifteen years ago, when a deprecation warning made a developer feel like a clock was ticking, and when the timer ran out, their code wasn’t going to work anymore. That would be true if deprecated methods were ever pruned out of the Java SE suite of APIs, but they never are.

I still see users calling the deprecated java.util.Date() constructor. The last project I was on was replete with calls to the deprecated URLEncoder.encode(). Sure, people shouldn’t be calling Java’s deprecated methods, but given the fact that they work, compounded with the fact that fifteen to twenty years after being deprecated they’re still hanging around as part of the API, developers just keep using them. Simply telling developers to ‘get with the program’ clearly isn’t good enough.

Java method deprecation and backwards compatibility

So why do they keep leaving all of these deprecated methods in the spec? I was once told that pruning usually happens on a full increment release, and since Java has never transitioned to version 2.0, there’s never been a need to.  (Although Java boasts version 7 and version 8 releases, the actual version increment is 1.7 and 1.8.) There’s also something to be said for backwards compatibility. Not removing deprecated methods from the spec makes old code forward compatible with future compilers, and that certainly makes maintaining old code easier.

But the Java approach to never pruning deprecated methods out of the spec is not a universal one. In contrast, Spring has always been aggressive in taking unloved functions out of the codebase. “It seems that the view of Java is that deprecation means nothing, whereas our view of deprecation is that if you deprecate something, you take it out in the next major release,” said Rod Johnson a number of years ago when discussing the Spring framework and it’s dedication to backwards compatibility.”Deprecation actually says something. It says ‘this is going to disappear in probably 18-month’s-time.’”

The fact is, whether it’s the JVM’s gc process to blame or not, the finalize method  never did what it was supposed to do in the way that people expected. That in itself is reason enough to vote it off the island, so the @deprecated flag is certainly warranted. But don’t just deprecate it. Grab the hedge clippers and put together a plan to cut it out and throw it in the garbage. Of course, that really is the problem, isn’t it? Java has never had predicable garbage collection services.

You can follow Cameron McKenzie on Twitter: @cameronmckenzie

March 27, 2017  2:03 PM

Agile and DevOps aren’t two magical unicorns of software development

cameronmcnz Cameron McKenzie Profile: cameronmcnz

There’s a listicle over at the TechRepublic entitled Top 10 challenges to DevOps implementation (linked below). So what are the challenges? They list off the standard things such as culture and skillsets, planning and tool.

I’d be criticizing the daftness of the list if it wasn’t for the fact that I’ve written or published more articles than I’d like to admit with similar themes. I think there was a three month period where I was instructed to gather up as many different insights into how to make DevOps work, and every article I wrote on the topic seemed to focus on culture, skills and planning, with culture always getting the majority of the focus. Here are just a few examples:

The problem is more fundamental than a DevOps transition

Here’s my issue with these types of articles. An organization’s lack of skills, planning and proper tooling isn’t causing DevOps adoption to fail. The lack of those things is what’s causing the organization to fail in general. When people talk about ‘culture’, what they’re talking about is a common mindset. If your IT department is made up of a bunch of people pushing in different directions, the problem isn’t with DevOps adoption, the problem is with the IT department as a whole.

It’s always been my opinion that switching to DevOps works for the same reason Agile works, and it has nothing to do with the methodology itself. The reason the move to DevOps or Agile works is because it gets departments that weren’t doing testing, weren’t doing quality control, weren’t hiring the right people and weren’t using the right tools starting to do all of those things properly. If those flailing organizations put all of these things into motion but kept the barriers between development and operations in place they’d likely see all the same benefits, and if they did all these things but stuck to a waterfall development approach, they’d see progress there too.

There has to be a method

I’m not one who goes around advocating a particular methodology because I don’t believe any of them work any better than the others. What I do know is that organizations who don’t have a methodology at all are bound to fail, so when organizations who don’t have a method adopt one, they encounter success.

The TechRepublic article is right. If your organization doesn’t address the ten challenges it mentions, your DevOps implementation is going to fail. But if your organization is struggling with those ten challenges it discusses, your organization is doomed to failure regardless of whether it’s implementing DevOps or not.

Top 10 challenges to DevOps implementation – TechRepublic

March 27, 2017  1:25 PM

Are you a Hadoop pro?

GeorgeBailey Profile: GeorgeBailey

Through this Big Data Hadoop quiz, you will be able to revise your Hadoop concepts and check your Big Data knowledge to provide you confidence while appearing for Hadoop interviews to land your dream Big Data jobs in India and abroad. You will also learn the Big data concepts in depth through this quiz of Hadoop tutorial.

So before we start the quiz, let us revise our Big Data Concepts and key Hadoop features due to which Big Data Hadoop has captured IT market so fastly with various Hadoop roles and has tremendously increased Hadoop jobs and salary.

Play Hadoop Quiz Now>>

Page 1 of 1412345...10...Last »

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: