Triaging Magento 2 GitHub Issues

In my post "Magento 2 in 2017 - How's Things?", I brought up the point that the Magento 2 GitHub repo has averaged 11+ new issues per day in the past 30 days (and that includes a relatively slow period, between Christmas and New Year's). A large number of these issues are irrelevant, blank or otherwise adding noise that makes it hard for Magento to identify what the high priority/high impact issues are. If those issues can't be identified quickly, then the quick resolutions we're all hoping for certainly aren't going to happen. 

From looking at Twitter, the community obviously really wants to help Magento with this issue, and Magento is working on this problem as well. So I want to help improve that debate and discussion by adding a few more thoughts and a point of view that may not have been considered yet. As always, I'm trying to bring a new angle to the conversation, so if you disagree or have a different point of view, hit me with it on Twitter or here in the comments.

First, let's do a little experiment. Go to the Magento 2 GitHub Issues page - https://github.com/magento/magento2/issues - and without reading the titles, just click blindly on one of the issues. Read through it, and assuming it's not complete gibberish, do the following:

1) Attempt to reproduce it on a clean installation of Magento 2. If you need a Magento 2 dev environment, check out MageScotch (http://github.com/joshuaswarren/magescotch/) and you'll have a clean Magento 2 install ready to experiment on with very little effort.

2) If you can reproduce it, drill down to what area of Magento you think the bug is coming from and write up a brief summary of the issue and some potential causes and the overall impact the issue has.

3) If you can't reproduce it, write up a brief summary of any reasons why you might be having trouble reproducing it and the results that you do see when you reproduce it. 

Alright, now stop, and look at how much time has passed since you started this experiment. Now multiply that by the 11+ issues per day that are coming in to the Magento 2 repository - and you see the scope of the problem we're talking about.

I can hear some of you saying "Hey, I'm not a Magento 2 core developer, so of course I'm going to be slower at this because it's not what I do all day". However, you have to remember that the Magento 2 core team is very, very large. I doubt there's any single developer on the core team that truly knows the entire Magento 2 codebase, top to bottom, inside and out, to an expert level. This isn't because they aren't smart developers - it's because when you have a team of 100+ developers working on a massive framework that covers so many different functional areas, the only thing that makes sense is to have them specialize in a specific area of the codebase. So if you take any specific core developer and assign them to triage Magento 2 GitHub issues, there's a good chance that on any given issue they're looking at, they'll be looking at an area of Magento 2 that they aren't an expert on. 

The problem then becomes - do you interrupt the developer that is an expert on that part of Magento 2 in order to triage each new issue that comes in for their area? Or do you have a team with general knowledge of Magento 2 just do their best to triage the issues that are coming in?

This is the same challenge that community volunteers face. No single community member knows Magento 2 inside and out, top to bottom. We all have our areas we're more and less experienced with. 

So, as far as I can see, there's no solution to greatly reduce the amount of time spent triaging these issues, because almost any way you structure it, the developer(s) triaging the issues won't be experts in every area of Magento 2 that has issues opened. 

There's also a psychological challenge here. Long, long ago, I worked in a job where I spent part of my day triaging and answering technical tickets opened by customers. At the top of the screen I worked from, there was a counter of how many tickets I had touched that day. Management watched that number, and used it as a measure of my work effort. Replying to a ticket and simply asking for more information, spending hours producing a patch for a client or just simply closing a ticket as "won't fix" all counted exactly the same. We also could see a count of the total number of open tickets, and felt psychological pressure when the count was increasing instead of decreasing. While I did my best to always provide excellent service, I definitely watched as some developers would pad their numbers by closing tickets. Over time, I noticed even good, honest developers would err on the side of closing tickets as "can't reproduce" more quickly than they probably should, simply because it made all the numbers look better, which made them feel better.

I definitely saw this happened on the Magento 2 GitHub Issues in early to mid-2016; I watched as issues that were important issues were closed quickly as "can't reproduce" with really no other details. I understand the pressure + when so many issues that are opened truly can't be reproduced, it's easy to fall into the habit of just closing things as can't reproduce.

So, how does Magento Inc structure things so that issues are quickly triaged, classified and prioritized? Knowing that it's going to take a lot of time, and that any metrics that try to decrease the time it takes for issues to be triaged are likely to cause issues to be handled inefficiently, what do you do? 

The best thing I can think of so far - and there are aspects to this idea that I don't like - is a method by which issue reporters are measured, and issues opened by 'known good' issue reporters are treated differently than issues opened by people opening their very first issue, and. both of those groups of issues are treated different from issues opened by issue reporters that have a history of opening low quality issues. 

Basically - the first time you open an issue, you have no history on the repo, so the issue is triaged exactly like it is now. As the issue is triaged, it's tagged as basically well defined, needs improvement or outright closed.

Then, as you have opened more issues over time, if your previous issues have a history of being tagged as well defined, those issues are triaged before the ones that are opened by individuals with a history of issues that are outright closed. 

There's a couple of things I really don't like with this idea - first, I don't ever, ever want to discourage people from contributing to the Magento community in any way. I hate things that even give the hint of elitism. Second, sometimes, very important issues are opened by 'first timers', and I don't like that those would be treated with a lower priority. 

Perhaps there could be a way for anyone that has a history of having their issues tagged as well defined to 'vouch' for an issue, lending their credibility to the issue? 

This is probably a terrible idea. But it's the one I have right now, and maybe it will spark an interesting conversation or other suggestions. What do you think?

 

Magento 2 in 2017 - How's Things?

This is a quick, personal post inspired by Karen's recent post, "What Magento Should spend some of that 250M on". Karen's post inspired me to break my entirely-too-long hiatus from blog posting to provide my personal viewpoint on Magento 2 and Magento Inc as we go into 2017. I don't have the time I'd like to dive into every aspect of M2 and Magento Inc or to blog as much as I'd like, but I want to put a few points out there for discussion and debate in the community. 

First, a disclaimer. I am not an extension author. I've written Magento 1 extensions and I've written Magento 2 extensions. But my livelihood does not come from extensions. My company, Creatuity, is a Magento Enterprise Solution Partner. Our bread and butter comes from building and supporting sites, not from extensions. Twice, we have experimented with a foray into Magento extensions for fun and profit thinking it would be a good way to diversify and twice I've decided that I have no idea how companies survive on extensions alone. So, I don't have first-hand experience with some of the pain that Karen's article expresses, because while we're porting some of our internal-use extensions from M1 to M2, we're not an extension company supporting both M1 and M2. 

Next up, there's a few items I agree with Karen on whole-heartedly. Specifically, in 2017, Magento Inc has to make a substantial investment of time, money and energy into:

1) Bug fixes. Teams and processes dedicated just to solving bugs and releasing updates as quickly as possible. There were some very large shifts in Q4 of 2016 and those that have been tracking Magento 2's roadmap have noticed that the focus shifted rather intensely in 2.1 from planned features to bug fixes, and that's appreciated. The grumblings I'm hearing are that further changes to speed up bug fixes are in the works, but I know first-hand from running a large agency that modifying development workflows and processes for a large team of developers takes a lot longer than any of us would like. I think there's an underlying problem here, though, that no one's really talking about that I will touch on later.

2) Engaging the community more in direct, measurable ways. Make more of the roadmap truly public, and engage the community (be they individual community developers or official Magento partners) with the roadmap. Work with the community and appreciate the community. Like Karen, I absolutely love what Ben and Sherrie have done to appreciate the community. I don't know a single Magento community member who can truthfully say that they've interacted with Ben or Sherrie and left the interaction feeling anything less than appreciated. Ben and Sherrie, however, are two people among an organization of over 500 people. There's only so much they can do. 

The other 498 - I know many amazing people that work for Magento Inc from the very top of the organization down to the 'rank & file' that are amazed by the Magento community and that really get that Magento's success is, and always will be, on the strength of its community. However, there are still pockets within Magento Inc. that have never worked with a community like ours before. They don't "get it", not because they don't care about the community, but because their role at Magento Inc hasn't allowed them to see first-hand the impact the community has on Magento's success. They're not achieving the success or the productivity that they could be achieving because they don't realize how the community could help them, or that the community is here to help. 

Now, a few things I disagree with, or would at least like to provide a counterpoint to Karen's article on. 

"In the last 12-18 months I’ve seen several serious size agencies get ‘burned’ by Magento."

We've had some bumps in the road in our relationship with Magento - keeping two large, fast growing companies aligned isn't easy. However, we definitely haven't been burned. We made a point to get out ahead of Magento 2 very, very early, and that experience really allowed us to grow and deepen our relationship with Magento in 2016. Maybe some other agencies have been burned, but it's not something I've experienced or witnesses.

"I’ve also heard agencies tell me similar stories, at best many have just flatlined in 2016 after years of high growth."

Creatuity has a track-record of high growth, but 2016 was phenomenal. Record-breakingly so. We completed twice as much work in 2016 over 2015. The majority of the work we did in 2016 was on Magento 2. Just like I think it's a stretch to say that an agency experienced a decline in 2016 due to Magento 2, I don't want to attribute all of our growth in 2016 to Magento 2. We worked very, very hard. We depended our partnership with Magento Inc and closed what I suspect may be more Magento 2 deals in 2016 than all but the largest partners. So, Magento 2 isn't a magic bullet that led us to substantial growth - but being on the forefront and fully trained up on Magento 2 before 2016 began definitely helped us substantially.

" Some say project times are shorter, I’ve never seen a project of any complexity that has come in faster than M1."

I'm one of those people that's been saying that; I noted it on many of my Magento 2 presentations in 2016. At Creatuity, we've used the same time tracking system since 2009. As any of our team members I'm sure would be quick to tell you - I'm almost Orwellian when it comes to time tracking. Billable time, internal time, it all gets logged down to the minute and to the project or training area. So I can say with confidence, we have had complex tasks take substantially less time in Magento 2 than Magento 1. This is after our team was trained on Magento 2, and after we built up a robust toolset around it. However, looking at our training and toolmaking time; in 2015 we spent about 5% of our time on that. In 2016, that increased to only 7%. I stand behind my previous statements that once a team is up to speed on Magento 2 and has the right tools and knows how to use them, projects are more efficient under Magneto 2 than Magento 1. Now - if you run up against a bug, yes, that will delay things (and I'll discuss that further, below).  

"And for those of you developers ‘evangalising’ about how great it is – maybe it is great when its your hobby and you aren’t seriously working on it or your merchant is willing to spend a ton of money effectively training you."

For better or worse, Magento has never been a hobby for me. And merchants most certainly won't spend a ton of money effectively training me, or our team. We've fought for every bit of Magento 2 knowledge and every line of code in our Magento 2 toolchain. And we've struck a balance between investing in internal training time and working with merchants that are excited about Magento 2 to ensure those investments pay off. 

Was it easy picking up Magento 2? No. Neither was picked up Magento 1, though. However, I hit a tipping point midway through 2016, where going back and working on Magento 1 projects 'hurt' a little. I realized that I had been immersed in Magento 2 long enough that the tools and the processes made much more sense to me, and I can truly say that developing for Magento 2 is great. I love it, and I will celebrate the day our final Magento 1 client has migrated to Magento 2 so that we no longer have to work with Magento 1. Also, as embarrassing as this is to admit - I was really, really bad at writing modules in Magento 1. For some reason, the approach didn't make sense to me and I always managed to muck something up. In Magento 2, I'm cranking out modules left and right - faster, fewer errors and overall more cohesive. 

This post is already substantially longer than I intended. So, I'm going to stop here and just focus on two areas that I think aren't being discussed enough:

First - yes, there are agencies (and in turn, merchants) having bad experiences with Magento 2. Sadly, halfway through 2016 we already had to take on our first 'rescue' project from another agency that failed in a Magento 2 implementation. From the failed implementations I've been brought in on thus far, those failures seem to stem from a few things - they tend to be agencies with no Magento 2 experience or training that decided to try to learn Magento 2 'live' on a client project. They tend to be agencies that underbid projects in order to win them. They tend to be agencies that don't have a formal relationship with Magento, or have a distant relationship at best. And you know what? I saw the exact same thing with Magento 1 projects in 2009/2010. The hardest case to watch was one Magento 2 project where the agency and the client did everything right, and then bumped up against a bug in Magento 2. In that case, luckily, the bug was well documented in a GitHub issue and resolved. So, while it delayed the launch of the project, it didn't cause the agency or the merchant to incur any additional costs. 

Second - bugs. I cringe when I see people quoting stats on the number of open issues on GitHub. As a community, we implored Magento to open things up and bring their code and their issue tracking onto GitHub. And when they did that, some people then started using it against Magento. There are competitors using the number of open issues on GitHub as a sales tactic against Magento. That really frustrates me, and I think one of the biggest problems right now are GitHub issues in general.

Don't get me wrong - I never want to see Magento step back from GitHub and GitHub Issues. I think doing so would be a very, very poor decision that would lead to a contraction in the Magento developer community, and in turn, a contraction in Magento's marketshare. 

However, there have been over 8,000 issues opened on the Magento 2 repository. 1,548 opened, 5,286 closed and apparently over a thousand merged or deleted. In the past month, over the holiday season, the Magento 2 repo averaged over 11 newly created issues per day.

Have you scanned through those issues? I just browsed through the first couple of pages, and I found:

1) Issues related to Magento 1, not Magento 2. (i.e., #8030)

2) A substantial number of issues opened with little to no details and then no reply from the original author when the Magento team asks for details. (i.e., the entire Needs Update tag, which covers about 10% of all open issues right now, or #8006)

3) Major new feature requests that are only tangentially related to the Magento 2 software itself. (i.e., #8040

4) Issues with literally no content at all (i.e., #8031

5) Issues caused by poorly written (and in many cases encrypted) third party extensions (i.e., #7950).

Don't get me wrong - Magento 2 isn't perfect. No piece of software is. But the Magento 2 GitHub repository has a major signal-to-noise ratio problem. At 11 issues created per day, if it takes an average of 45 minutes per issue to classify the issue, confirm if it's a problem or not and then close/resolve/update/process the issue, then managing the intake of new issues in the Magento 2 GitHub repository would be a full time job for a single developer. 

What's the solution to this? I'm not 100% certain. I checked three large open source projects that came to mind on GitHub (the Linux kernel, Laravel and WordPress) to see how they manage this issue - they don't. They've completely disabled the ability to open new issues. They don't use GitHub for tracking issues at all. 

I know that Magento has experimented with community volunteers to triage GitHub, but the challenge then becomes ensuring they aren't encouraged to close issues too aggressively. These GitHub issues need the appropriate attention, because there are long-running issues that are lost in the noise. 

So - we all agree (and while I don't speak from them, their actions say to me that Magento Inc agrees as well) that Magento needs to make a substantial investment in fixing bugs and closing GitHub issues in 2017. However, how do we propose they do that? How do you manage the level of noise on GitHub and zero in to the issues that absolutely need to be fixed versus those that are user error or are obscure edge cases only impacting a few users? 

I mean those questions very literally - community, how do we propose they fix this? Do you know of GitHub repositories with thousands of issues, opening at the rate of 11+ per day, being triaged and managed well? If so, speak up, and let's continue to build on the success of Magento 2 in 2017. 

This post is already entirely too long - if you read all the way to this point, you have my thanks - come up to me at Magento Imagine in April and say "I am Magento" and I'll buy you a drink to make up for the time you've invested in reading this. 

Let's keep building great things, let's stay passionate and let's keep pushing Magento (the platform, the community and the private company) forward in 2017!

Creatuity Reviews

Building and growing an eCommerce agency has taught me more than I ever imagined it would've. I'm going to be writing more about these lessons and other interesting things I've learned over the years. First up - reviews, testimonials and references. 

Vetting a potential vendor, partner or supplier is hard in the digital age. You'd think that the web would make this problem easier, but it's just introduced new challenges as well as new opportunities for dishonest actors. 

I'm not going to pile onto the Yelp bashing bandwagon - there's enough articles out there that cover the problems with Yelp. Instead, I find it interesting to think through things as a customer trying to vet a potential vendor in the digital age. For instance - I occasionally talk to merchants who are considering hiring Creatuity or another Magento agency and they openly admit they aren't sure how they can vet a potential agency. 

Many years ago, I wrote what in retrospect may have been a well-meaning but slightly aggressive article on the Creatuity blog called "Requesting References and Other Mistakes When Hiring a Web Developer". In that article, I call out the fact that generally no one is going to give you a reference to call that will say something negative about them. 

So, if references are out, how do you determine if a company is legitimate? Many people Google for online reviews - i.e., searching for Creatuity Reviews or Magento Reviews, etc., before making a decision. Because if you find a lot of good (or bad) reviews online, and a large presence on Facebook, Twitter and other platforms, then the business must be legitimate, right? 

Wrong - as a journalist proved last year, it's possible to setup a completely fictional business, generate positive reviews on Yelp, a massive following on Facebook and Twitter and all of the other digital footprints of a successful, positive business. After seeing what some less ethical businesses have done online, I wasn't shocked by this article, but I was surprised at how easy it was for her to generate enough of a positive digital footprint for a business that never existed. She even produced photos of a happy customer in front of what appeared to be the business! 

This story, combined with Amazon's recent move to ban incentivized reviews after many Amazon sellers completely manipulated Amazon's rankings and search results through these reviews has me more disillusioned than ever with online reviews and verifying the legitimacy of a product, service or company in the digital age. Combine this with the fact that at Creatuity we've caught competitors astroturfing fake support for their company and using the same tactics to negatively impact the online reputation of their competition, and I'm ready to swear off reviews altogether!

So, what's a person to do? The journalist who created the fake business said that she was only going to trust online reviews from people she personally knew and trusted. Given just how much shopping I do online, I don't think I know enough people to be able to use my personal network to learn about the merits of every product or service I'm considering! For larger purchases, potential vendors and partners, I'm going 'old school' to a degree - I'll be looking to conferences and other in-person events to meet and vet potential vendors. While some of these events are also pay-for-promotion, there are still good events out there that offer the opportunity to collect unsolicited, unbiased feedback on vendors. 

For smaller purchases, I've been experimenting with the tool FakeSpot to identify which products have genuine reviews on Amazon. Sadly, the vast majority of the products I've checked have scored a D or F on FakeSpot.

What challenges have you faced while vetting products or services online? How do you go about determining if a product or service is legitimate? Share your thoughts in the comments, below. 

 

Another Example of Great Changes at Magento

So, in the past few months, Magento has moved out of the eBay family and has returned to being a private company. There's been some shakeups internally with some key new hires and the org chart has been shuffled around some. Some people seem to be a bit nervous about all of the changes, but I've remained positive all along. Magento's strong community and foundation in open source software has kept it growing strong throughout a number of major changes in ownership over the years. 

I'll dive deeper into all of the recent changes and the positive impact I'm already seeing from them, but I wanted to highlight something that happened today that just wouldn't have happened a couple of years ago at Magento when it was part of the eBay family. 

A Magento community member, Kristof (better known as Fooman, the name of his Magento extension company), Tweeted about a 'gotcha' when using Composer with Magento 2:

Magento Evanglist Ben Marks retweeted this with a question about if this should be added to the Magento 2 documentation:

I took a look and realized this was a simple change, so I wrote up the needed documentation and submitted a pull request which the Magento dev docs team reviewed, accepted and merged within 7 minutes!

So, to recap:

  1. Magento 2 launched with an extensive set of developer and user documentation.
  2. Pull requests are accepted both on the Magento 2 core code and the documentation.
  3. When the community notices something missing in the documentation, it takes ~12 hours (mainly due to the time difference between New Zealand, where Kristof is located, and the US!) for someone to volunteer to fix it, submit it to Magento and get it accepted into the main documentation. 

How awesome is that?

Josh Warren vs Joshua Warren

I'm often asked - Josh or Joshua, which do I prefer to be called? And, well, the answer is more complicated than you would think. In casual, in-person conversation - say, we run into each other at a conference - feel free to call me Josh or Joshua, I'll answer to either and have no real preference.

However, if you see me present, read an article I write or ask me how I prefer to be addressed in a professional setting, you'll always see me listed as Joshua Warren, never Josh Warren.

Why? You might not believe it, but - for SEO reasons!

You see, my parents accidentally gave me one of the most common names in the United States! There are over 600,000 men in the United States named Joshua - it's the 38th most common male first name in the US. There's almost 200,000 Warrens in the United States - it's the 138th most common last name in the US. So, 'Joshua Warren' isn't quite as bad as 'John Smith', but it's close!

This wouldn't be a big deal, except, well - as you'll see if you Google, there's another Josh Warren who works in online design and development. And if you search for Joshua Warren - well, brace yourselves, because there's a rather interesting individual out there who shares the name Joshua Warren with me.

So, I decided a few years back, when I was able to secure joshuawarren.com, that I would consistently use Joshua Warren instead of Josh Warren as my name in professional settings. My hope is that if you ever happen to link to me or mention me online, you'll use my full name - Joshua Warren - and that if enough people do this over time, I'll be easier to find online when you search for Joshua Warren.

What I Wish Someone Told Me Before My First Trip To Magento Imagine - 2015 Edition

Are you headed to the Magento Imagine conference in April? If so, you might want to check out what ended up being my most popular article of 2014 - What I Wish Someone Told Me Before My First Trip to Magento Imagine. A majority of that article is still relevant for #ImagineCommerce 2015, with a few tweaks and new hints:

  1. Imagine 2015 is back to its usual spot on the calendar in April instead of May. That means it won't be quite as hot, but Vegas still averages a high of 80 F and a low of about 60 F during that week of April each year. It's entirely possible it will be even warmer than that - as I write this, the forecast for the next week for Vegas has highs as high as 91 F. The evening events will be cooler this year than last year, though, from the looks of things.
  2. I just want to really emphasize what my original article says about how quickly Imagine passes by. If you see someone you've always wanted to talk to - stop, and talk to them. Even if you miss a session, do it, because before you know it Imagine will be over and we'll all be headed back home. There's several people I wanted to talk to last year that I just didn't get a chance to because I said "I'll catch up with them tomorrow"
  3. Don't assume you have to go to every single session to get the most value out of Imagine. Doing so may leave you exhausted, overwhelmed and missing out on some of the best conversations that are held in the hallways, on the casino floor and throughout the hotel.
  4. This year's event is at the Wynn. The Wynn has a great location on the Las Vegas Strip - across the street from Fashion Show Mall, and at the same intersection as Treasure Island, the Mirage and the Venetian. If you time it right, you can walk down to the Bellagio (a bit less than a mile from the Wynn) and see the fountain show there, then walk back towards the Wynn and catch the volcano at the Mirage on your way back, along with seeing a number of the great Vegas casinos on your way.
  5. The official hashtag this year is #ImagineCommerce. Also, a number of Magento community members now use the hashtag #realmagento instead of #magento due to the amount of spam that occurs on the #magento hashtag.
  6. Speaking of hashtags - some of the greatest unplanned, spontaneous happenings at Imagine are organized on Twitter. Even if you never tweet, keep an eye on the #ImagineCommerce hashtag or follow me on Twitter - @JoshuaSWarren - and stay in the loop with what's going on at Imagine.
  7. A number of community members have written their own guides to Imagine. If you've written one, send me the link on Twitter and I'll post it here. So far, I recommend starting with the 'Taking Advantage - Magento Imagine' article by Karen from WebShopApps.
  8. If you haven't already, go back and read last year's article - What I Wish Someone Told Me Before My First Trip to Magento Imagine - it has even more great tips for your trip to Imagine.

I'm looking forward to seeing old friends and making new ones at Imagine this year. If you see me at the conference, please don't hesitate to say hi! Don't worry if it seems weird to introduce yourself to someone you follow on Twitter but have never met; I've gotten very used to people saying "Hi, Josh! I follow you on Twitter!".

Why I Built Launchpad & How It Will Create More Clients For You

Launchpad? What's That?

If you haven't heard about Launchpad yet, it's an affordable, powerful Magento-based eCommerce system that is completely different from all of the other packaged Magento installations out there. It's affordable ($4,000), has no ongoing license fees (it's a one-off purchase) and it's completely open.

Why'd You Build It?

Launchpad hasn't been a cheap project - our team has invested over 800 developer-hours into it at this point. Other agency owners are no doubt running the numbers in their head now, thinking about how much revenue those developers could've generated by working on custom Magento implementations for large customers. But I've kept investing in Launchpad to get it to where it is today for a very personal reason - I'm passionate about freedom, openness and creating a level playing field for all merchants.

I believe that a merchant should:

  • Have the same level of features on their eCommerce site, no matter what their budget is. Great products and great service should win the battle for the consumer's dollar, not just great budgets.
  • Be in complete control of their business, able to change hosting providers, agencies and platforms when they feel it's appropriate, and never be locked in.
  • Build a successful online presence on truly open technologies.

Some of the cloud-based eCommerce systems out there solve that first item, but not the other two. Systems like Magento solve the second two, but not the first one. So, I set out to build something that would combine all of the features and affordability of the cloud-based systems with the openness of Magento.

Why Should I Refer People to Launchpad?

As an active member of the Magento community, I feel like it's important that we as a community have a Magento-based option for every size merchant, but especially the smaller merchants, and those options should make it easy to move up. When smaller merchants are referred to BigCommerce or Volusion or the like, they're gone. Those cloud-based systems sink their teeth into them and do everything they can to keep them. They're generally never going to come back to Magento, no matter how large they grow.

So, if we want our ecosystem, our community, our marketshare to continue to grow and be healthy, we have to direct merchants into an option that gets them "hooked" on Magento while still allowing them to grow and move from an entry-level option to a more serious Community-based option all the way up to a fully custom Enterprise build.

I'm hoping Launchpad can fill that role - it's designed so that after the site is launched, the merchant can take it to any agency, any freelancer, or even maintain it themselves. So you can send merchants to it and know that we're going to convert them into Magento users that remain active in the Magento ecosystem and will continue to have a need for a Magento developer, Magento extensions and other services for years to come.

So, next time you come across a merchant who is looking for an eCommerce site but doesn't have the budget for a custom Magento build, I hope you'll refer them to Launchpad. For $4,000 we'll get them live on a solid, open Magento-based solution in just 2 business days, and once they're live, they're free to hire you for any other work or services they need. It's truly a win for everyone in the Magento community every time we sign a new merchant up for Launchpad.

I'm anxious to hear any feedback the community has - I want this to be a solution that the community feels strongly about, so if you have any questions, comments or concerns, please post them here or reach me on Twitter at @JoshuaSWarren.

This Matters: Support Brent's Run For Research

I wanted to take a moment out from my usual banter to call attention to a really amazing member of the Magento community and a charity event they're involved in right now. Brent Peterson is running the Boston Marathon this year as part of Run for Research, an American Liver Foundation fundraiser. Before I dive into the details, please, take a moment to visit his fundraising page and contribute $25.

I'm supporting Brent's run and encouraging you to do so for two reasons - first, because of how Brent has inspired me, and second, because of the importance of the work the American Liver Association does and the impact it's had on my life.

About Brent - if you're involved in the Magento community, active on Twitter or have ever attended Magento Imagine or another Magento event, then you know Brent and he needs no introduction.

For those of you who don't know Brent, he's been involved and active in the Magento community for a number of years, he's active on Twitter and he loves to run. He's not one of these guys that every January says "Hey, I'm going to exercise now" and tweets about it non-stop. Nope, he's a die-hard, day-in-day-out, runs every chance he gets sort of guy. If there's a Magento event, chances are Brent has found the nearest race and is not only running in it, but also encouraging other event attendees to run as well.

And that's what has really inspired me. Brent is dedicated to running, and to encouraging others to run and live a healthy lifestyle. Too many people in the Magento/development community are sedentary, myself included. And too many of us lack the inspiration, the drive and the follow-through to change that, but Brent is right there encouraging us and serving as a solid example even when so few of us take action and start exercising. I've never heard Brent say a negative word about someone because they don't exercise, but instead I hear him constantly encouraging people to give it a try.

So, as a way of saying thanks and recognizing the positive impact he has in our community, I encourage you to donate to Brent's Run for Research.

The other reason I encourage you to donate is because of the cause - the American Liver Foundation. The American Liver Foundation is working to eliminate liver disease, and in the process is providing education, research, support and advocacy around liver disease.

Liver disease isn't something we hear much about, and there's a lot of misconceptions about it. For instance - did you know that six million children in the US (10% of all children in the country) have been diagnosed with non-alcoholic fatty liver disease? Among different types of cancer, liver cancer consistently has one of the worst 5-year survival rates. While other diseases and disorders get a lot of attention, as a society we just don't talk about liver disorders very often.

Personally, I'm very aware of the impact of the work the American Liver Foundation is doing because I watched a great man struggle with liver problems, and thanks to the type of work the American Liver Foundation is doing, he received a liver transplant and was given several more healthy years of life, during which he had a great impact on the people around him and his community.

So, please take a moment to donate to Brent's Run for Research - it's a quick online form, and you can enter any amount you'd like to donate. You have the option to be anonymous, and they take all major credit cards.

Please share the link to Brent's donation page with everyone you know - if we can get 150 people to donate $25, Brent will meet his fundraising goal and we'll all be supporting a great person and a great cause during the 2015 Boston Marathon.

Choose Your Own Adventure: Freelancer or Founder - Out Now in php[architect] magazine

I'm excited to announce that my article, Choose Your Own Adventure: Freelancer or Founder, appears in the January 2015 issue of php[architect] magazine, which is available online and in print now. I drew on my experiences as a freelancer who found himself rather unexpectedly growing into the founder of an eCommerce development agency to write what I hope is a very applicable, hands-on guide for all of the developers out there considering striking out on their own either as a freelancer or as the founder of their own agency.

php[architect] is a great magazine that I encourage all PHP developers to subscribe to - there's both a print as well as digital subscription, and I've been impressed with the quality of the articles each month.

If you have any questions or feedback on my article, please don't hesitate to post it here or reach out to me on Twitter at @JoshuaSWarren.

A quick thank you to the Magento community and MageHero.com

I just wanted to take a second to say thanks to everyone out there on Twitter, on MageHero.com and to the Magento community as a whole. I've grown Creatuity very slowly over the years - we don't really have a marketing budget, or marketing department for that matter - it's all been on word of mouth and referrals and developing a reputation for solving some of the most challenging problems with Magento and taking really good care of our clients while doing it.

Because of this, every single referral means quite a bit to me and to all of us at Creatuity. That's why I wanted to say thanks - we've seen a sharp increase in the number of merchants coming to us saying they were referred to us by someone in the Magento community. A story I heard about how a client found us a couple of weeks ago is a great example of this.

This merchant first saw me on MageHero.com and reached out to a few other people on MageHero first. Almost all of them indicated they were too busy to take on the project, but that they should call Creatuity for help, because we'd take care of them.

So - to all of you who have referred merchants to me and the rest of the Creatuity team - thank you. I really appreciate it and I want you to know we will continue to do great things, so you can always trust that the merchants you send to us will be taken care of.

The Magento 2 Certification Problem

With all the discussion around the technology behind Magento 2, the release schedule and the excitement of how Magento 2 will help transform eCommerce, I have to admit, I hadn't thought at all about certifications for Magento 2 until someone at Magento asked my opinion about it. So here's the challenge - when Magento 2 launches, how will an employer or merchant know a developer knows Magento 2? Magento (both as a community and as a company) has always made it clear that they understand that a big part of the success of Magento is thanks to the large, vibrant community of Magento developers.

However, the current Magento training and certifications cover Magento 1, not Magento 2. New things are in the works, but with the release date of Magento 2 approaching quickly and fairly major changes still taking place in the codebase, how do you have a way on Day One of Magento 2's release to know a developer is Magento 2 ready?

In an ideal world, all of us Magento developers would be spending a significant amount of time staying up to date with the changes the Magento 2 team is pushing each week on Github, and we'd all be studying and learning Magento 2 in-depth over the next 11 months until Magento 2 is released.

However, Magento 1 developers are in high demand. We all have our Magento 1 work to do, and we all seem to be getting even busier.

So, let's say Magento 2 is completely feature/architecture frozen by the end of March (a date I made up, by the way, just as an example). The Magento 2 release date is Q4 of this year. For this example, we'll say that's on December 31st, 2015.

That works out to 9 months. 9 months to prepare a complete training program or certification exam, release it to the community and for Magento 1 developers to complete it. Split that time 50/50, and let's say Magento Inc spends 4.5 months preparing this information, giving Magento 1 developers 4.5 months between when the training is available and when Magento 2 goes live.

How many of you, while still completing your Magento 1 work and maintaining your other commitments could go from 0 knowledge of Magento 2 to ready to take and pass a certification exam in 4.5 months?

I'm sure there's some of you saying "Oh, yeah, that's more than enough time". And that's awesome. You'll be one of the trailblazers on Magento 2, and that's something the community really needs. However, that's not what the average developer is saying.

Here's an example - there's less than 450 Magento Certified or Certified Plus Developers in the United States. Let's say 20% of developers feel they can get trained up on Magento 2 and certified on it in 4.5 months (and from the conversations I've had, I think 20% is probably high). That means that if they all are able to achieve that, that gives the entire US market only 90 people who are able to become Magento 2 certified by launch day.

No one is really sure yet what user demand will look like - Magento 1 will continue to be supported for quite some time, so many merchants will stay on or implement on Magento 1 in 2015 and 2016. But there will also be quite a bit of buzz and excitement about Magento 2, and I have a feeling that there are many people on aging platforms that are waiting for Magento 2's release before they make the switch to Magento. Add to that how many merchants plan major projects or migrations for January, and you can easily see how there will be significantly more Magento 2 implementations than official trained/certified Magento 2 developers in December or January.

So, as a community, how do we handle that? How do we make sure we're not only preparing ourselves for Magento 2, but also making sure that merchants and employers are able to identify those developers who really are prepared for Magento 2? I don't think anyone has a practical, workable solution yet, so I'm curious to see what the community thinks and what we can come up with as we discuss this.

Making Magento go fast by Thijs Feryn @ThijsFeryn at #phpworld

Making Magento go fast by Thijs Feryn @ThijsFeryn at #phpworld Magento can be a little slow, but it's tremendously flexible.

Presenting today from the perspective of a hosting company employee who knows a lot about PHP but not a lot about Magento and approached it from a hosting/operational standpoint.

Remember the basics - activate caching, flat catalogs and JS & CSS minifcation.

The Magento compiler is a lie - it's invented for people who have no bytecode caching, but everyone should have that now.

Magento cache by default is on the disk - var/cache/

Move the Magento cache to somewhere faster. Could try APC or memcached. Memcached support allows multiple servers.

Magento uses a 2-level cache, a fast backend (adapter) and slow backend (disk).

You can put your slow backend (var/cache)on tmpfs.

PHP is slow - especially the older versions.

Remember - many types of PHP caching doesn't work well with fast-cgi because everything is in multiple, separate processes. Every process has its own APC cache.

With php-fpm you can configure a master process that stores the byte code cache so each child process uses same cache.

Opcache is awesome and a lot faster than APC.

Get all of your caches in memory!

The database is important for Magento performance - give MySQL more RAM. MySQL should use 80% of your database server's memory.

If you have lots of traffic to Magento, try turning off query caching and use the memory for the buffer pool and other uses in MySQL.

Check the setting innodb_flush_log_at_trx_commit - try to change it to 2 or 0.

Setup 2 database servers - one for reads, and one for writes.

Redis is GREAT - use it! Redis has built-in deplication, multiple data types, doesn't require a 2-level cache.

Store your sessions in redis so that sessions are shared between all of your web nodes.

Varnish is fast and scales - sites have powered 40 million users per day with only 2 Varnish servers.

Varnish only works on static items - product catalog and CMS pages. Not on checkout. It's great for static content, but it doesn't have SSL support. You have to terminate SSL before it gets to Varnish - use something like haproxy or nginix.

Look at using Turpentine - it allows you to use ESI or AJAX with Varnish and Magento.

If you can't use Varnish, use Lesti FPC.

If you're using Varnish or LestiFPC, turn off the visitor log tables, because they are no longer accurate. Convert them to blackhole tables.

Magento's default search can be a full-text search on the database - replace this with something better. Try using elasticsearch.

Host static files separately on a CDN.

Use Redis "clustering" to remove Redis as a single point of failure. Try Redis-cluster or Redis Sentinel - there's a Redis Sentinel patch for Cm_Cache_Backend_Rails.

 

What is new in Magento 2 with Tobias Zander @airbone42 at #phpworld

What is new in Magento 2 with Tobias Zander @airbone42 at #phpworld Ever since October 4th of 2013, the Magento 2 team has been pushing weekly updates to GitHub.

Magento2 is built on HTML5, CSS3, jQuery, LESS, requirejs. This means that Magento 2 won't support IE8.

Layout configuration is changing in Magento 2. Breaking the XML files into multiple files to make it easier to find what you need to change.

Unlimited theme fallbacks are coming in Magento 2.

Magento 2 currently has support of PHP 5.4 & 5.5. PHP 5.6 support will be coming soon.

Magento 2 follows PSR-0, PSR-1, PSR-2 and uses real namespaces.

XSD support for XML files is coming to Magento 2.

New file structure in Magento 2 so that modules have one folder, no need to install modules into multiple folders.

Magento 2 has Composer support. You can install Magento 2 from Composer.

Added the Service Layer to make things more reusable and easier to extend. More details at https://alankent.wordpress.com/2014/05/22/magento-2-service-layer/)

Dependency injections and interceptors are coming to Magento 2.

There’s great improvements coming for admin users in Magento 2 as well - adding products is MUCH simpler.

Magento 2 consists of 1.5 million lines of code currently. 2,600 integration tests. 7,600 unit tests. Not complete code coverage, but significantly better than Magento 1 which shipped with no coverage at all.

100 JS unit tests, over 100 static tests including PHP mess detector. 9 performance tests.

phpworld keynote: Turning Your Code into a Company: The Parts They Don't Tell You by Luke Stokes

Turning Your Code into a Company: The Parts They Don't Tell You by Luke Stokes - @lukestokes. Founder, CTO of Foxycart. Founded in 2007. Goal was to provide income for his growing family.

Starting a company is hard - it took 4 years of working full-time and then building Foxycart in the evenings and on the weekends, working as much as 10 hours on Saturdays. Don't believe the hype on TV - Shark Tank isn't real life. It's hard to build a company. But it's worth it!

A human being should benefit from what you do as a developer.

There's no such thing as an overnight success.

Getting "funded" is not a destination.

Build a business, not a startup.

Think about what do you believe - what will keep you motivated at 2AM?

Your focus has to be about the customer.

Belief that commerce technology makes the world a better place kept Luke going as he built FoxyCart.

Coders are insecure - we have a habit of hiding our code away. Don't be! Every failure is a step closer to success.

As a developer: solve problems, add value, keep learning.

Listen to your customers!

Motivation - passion is required, but it isn't enough. Who will talk you off the ledge? Think about paying customers. Encourage each other.

There's no glamour at 2AM - building a business is hard.

Solve real problems - if you'd pay for it, others might also.

How did Luke get to where he is with Foxy cart: slow and steady, grow the team with awesome people, focus on the product.

Focus on the product. Build a solid development team, not a sales or marketing team early on.

Fear can be healthy - don't make the jump to full time with your new company until revenue is a nice, consistent positive number.

There's great tools out there to help you build your company now. Check out http://bit.ly/foxytools for some recommendations.

php[world] opening remarks

Eli is opening up php[world] with the opening remarks. Welcome to the first PHP[WORLD]!

The goal is to bring the entire PHP community together.

Get out there and talk to people from other platforms/communities that are here today.

Twitter hashtag is #phpworld

WiFi is Sheraton_Conference, user: php14, password: sheraton14

Game night tonight, open source hackathon tomorrow night.

Open spaces - sign up for a slot. You don't have to be an expert on the topic, just talk about something you're interested in.

Please use join.in - https://joind.in/event/phpworld - provide feedback on all of the talks.

Visit the User Group Alley to learn more about some of the user groups that are represented here.

 

Beyond the Blinders: Unseen Opportunities in SEO Meet Magento New York 2014 Talk

This Meet Magento New York 2014 talk is "Beyond the Blinders: Unseen Opportunities in SEO" by Seth Dotterer. Search has fundamentally changed how consumers consume and how marketers market.

The average US adult now spends half their time online. Online is pulling attention span from TV, radio and print media.

Buyers are revolting against traditional marketing channels.

Web consumers choose organic content - no one is clicking on banner ads, and most click on organic, not paid search results.

1 out of every 2 consumers say they don't trust ads.

Great marketers engage early - get people at the awareness and exploration stages, don't just focus on targeting at the purchase point.

Many consumers now start their shopping experience by researching on Pinterest.

Customers strongly prefer the unpaid web. 90% of search budgets are going to 6% of the traffic.

Manage your content across all unpaid channels - Google, YouTube, LinkedIn, Twitter, Pinterest, etc.

Stop crowding the register (that's what everyone is doing, and you don't have their budget) - don't target people at the buying stage - back up and target them before they're ready to buy.

Seeking the Magento Community's Center of Gravity Meet Magento New York 2014 Talk

This Meet Magento New York 2014 Talk is "Seeking the Magento Community's Center of Gravity" with Kurt Theobald. Community events help us maintain a voice as a community driven ecosystem, so events like Meet Magento are important.

Magento really took off with the small and medium business market. That’s where Magento made its claim to fame.

Magento Inc is shifting focus to serve the mid-market, creating a gap with the small/medium business market.

Today is about discussing the problem and the path towards solving the problem.

Merchants have a challenging time getting any help from the Magento ecosystem/community.

Merchants have to find, evaluate and install solutions, but with so many countless extensions in Magento Connect it's challenging to find good solutions.

Magento Gold partnership doesn't mean quality - it means a company is willing to pay $10k/year for the label. This is because Magento’s business models towards the partner programs never matured. Let’s solve the problem as a community.

It’s very difficult for excellent partners to get the attention they deserve from Magento merchants.

As a community, let’s come together and lift up the high quality agencies that don't market well.

Let’s collaborate with those that do good Magento work and compete with the ones that do crap work.

Let’s marginalize and vaporize the fakers and superficial marketing fronts in the Magento ecosystem!

Right now the Magento community is acting like a bunch of independent cats, giving up what makes Magento powerful.

Let’s have a club mentality but let’s be virtuous - repel the junk and invite the quality.

It's not about any one agency - it's about protecting the Magento community by providing many quality options for merchants.

This isn’t a fork - we want to stay in unity with Magento.

 

Saving time and money with Vagrant - Meet Magento New York 2014 Talk

This is the Meet Magento New York 2014 talk "Saving time and money with Vagrant" with Tim Broder. Vagrant lets you QA server configurations for your Magento site just like you do your code.

Vagrant lets you setup a dev environment for a new project in 5-6 commands and about 10 minutes.

Everyone benefits from Vagrant - solo developers, startups, agencies, large scale businesses.

Vagrant helps with complex stacks - such as using Solr, Varnish, etc. - getting it all setup in one Vagrant box saves a lot of time.

Chef, Puppet, Docker, Ansible and Salt are all options for provisioning Vagrant boxes.

Slides, examples and much more are available here.

Magento Security and Us Meet Magento New York 2014 Talk

This Meet Magento New York 2014 tech track presentation is Magento Security and Us by Lee Saferite. Limit your attack surface - don't open unnecessary ports, and ideally use a server in a different subnet from your web server to provide SSH access into your site.

External log file storage - if your server is compromised, you can't trust anything on it. Transfer logs to a 3rd party service or another server in realtime.

Backup security - your backups contain all of your data - it should be secured well.

Your Magento site shouldn't have any writable PHP code - only var and media need to be writable, and they should only be writable by the web server user.

Magento extension authors should define specific, granular permissions in their extensions so that Magento site owners can restrict who can do what.

Don't install extensions directly from Connect - you need to run a code review/security audit first. You also don't want extensions that automatically update, because you don't know what their code might do.

If you're online for long and you're selling online, you will be a target, and at some point you will be compromised. Have a written incident response plan for what needs to be done when this happens so that you're prepared for it.

 

Persuasive E-Commerce Meet Magento New York Keynote

This keynote from Meet Magento New York 2014 is "Persuasive E-Commerce" by Guido Jansen. Online merchants have a big problem because online conversion rates are very low versus offline. Offline - 20-25% conversion rate; online is 2-10% conversion rate.

Online sales don't have the same level of personalization and sensory input as offline stores.

Automatic thoughts and actions drive much of our purchasing behavior. These are called heuristics in psychology, and they can lead to cognitive biases and prejudice.

Always be testing.

Social proof is a powerful force. Try things like in the past month X customers bought this product. This works well for socially acceptable products, but not for socially undesirable products.

Authority, liking and scarcity are other forces that persuade us to purchase.

There is no average customer - there are large individual differences.