“Because of a bug (it is an off-by-one error) the parley can only work if enemy and party member *do not* speak the same language.” One of the many memorable quotes from a fascinating article on an old school RPG by one of the developers. I don’t even know this particular video game, even though I was playing a lot of RPG during my Apple ][ and Amiga days, but this particular quote resonates with me because it ties game design and game implementation together in a very explicit way. The whole article is a must read for anyone who’s interested in game development or game design, or both.

A lot of founders I speak to struggle with finding a co-founder, particularly on the technology side. While they have an idea, they want to find someone who will help create that technology. Often development cost is a consideration, so equity seems like the easiest way to get address that. I find there's three big issues with this approach: If your problem was correctly validated, you'd be making enough sales that you'd be able to pay a developer to build out your idea. Pre-sell if you have to. Often, you don't need a product to make the sale. You need a solid understanding of your audience's needs to make a sale. At the same time, try to empathize with developers and understand their motivations. Developers are a curious bunch. Often, they're more motivated by getting to play with new technology. They want to solve difficult problems. Overcoming intellectual challenges. If you can frame what you are doing as an intellectual problem, you'll have a much easier time speaking with developers. Make sure that anyone you recruit as a co-founder is critical to executing your vision. Don't leave gaping holes. For example, one of Steve Blank's startups, a game building one, went bust. They didn't have a hard core gaming developer on the co-founding team. The easiest way to identify any major gaps in your co-founding team, take a look and your canvases (Business Model Canvas or Lean Canvas). Here's more: http://qz.com/321585/to-pick-your-perfect-startup-co-founder-do-this/ You may, in fact, need a developer. You don't need one until you've validated your problem and proposed solution. Otherwise, you're giving away your equity. Customers must clearly indicate that they're willing to pay for what you're thinking of building. Another good way of recruiting a technical co-founder is to ask the developer to help you interview customers. Have them help out with founders' work, what co-founders do. Have them interview customers about their problem. Then, once they get back into creating technology (where they feel comfortable) they'll benefit from a much clearer sense of what's needed. Not just what they hear from you. In that case, you can then focus on marketing, growth, and everything else your startup needs. The developer can build exactly the right solution.

concerned you might be not lean if you raise funding? that’s actually a pretty common myth related to the lean startup approach. let me ask you this. have you ever received a “recycled” present? while it’s clearly new, it doesn’t actually match your interests. in fact, you know that the giver received that present from someone else a few months earlier. it’s likely, therefore, that they never opened it, and just gave it to you. that’s similar to the day-to-day experience of a tech startup investor. i actually worked at a vc fund in the past. more on that in future emails. download a free chapter of launch tomorrow to get in on the action. many times a day, vcs get pitched equity in a tech startup. the founders don’t want the equity. they prefer cash. this immediately reduces the equity’s perceived value, in the vc’s eyes. in some cases, screams desperation. if the founders, who have lots of equity they got somewhere else, are willing to give it away…what does it say about the company’s value? about its prospects? about what the founders believe about the company? a common question that i get from people first looking at tech startups is why tech startups need so much money. after all, it shouldn’t cost that much to throw a product prototype together. isn’t it all just self-serving hype? not always. there are five strategic reasons to raise money in the tech startup world: funding customer acquisition hiring top talent the “land grab” the “pre-emptive strike” the cash flow shortfall so, starting from the top. in all but a handful of businesses, if you can’t buy customers, you don’t have a business. sometimes an idea takes off and goes viral. for the mere mortals out there, though, you need to figure out how to acquire customers and serve them profitably. paid advertising, in particular, has a bad name because it’s easy to misuse with other people’s money. it’s easy to fool yourself and others that something is happening, unless if you know what you’re doing. admittedly, most investors aren’t keen on providing money just to acquire customers, unless if you have already proven you can do this. turn $1 into $4. or $40. a marketing expense can reliably generate profit. recruiting talent to help you execute also costs money, particularly if you are breaking new ground technically. figuring out how to scale certain technical problems (like search or constructing social graphs) requires serious technical chops. the number of software engineers capable of doing that is pretty small. and the first guys who scaled google, for example, were self-taught. moreover, to be blunt, the guys in most cheapo emerging markets live in much smaller markets. they’ve never had to solve these problems in their home country. so you need to hire smart people and keep them happy. now–we get to the really good reasons why raising money is a good idea. the strategic ones. if you and your competitors are creating a completely new market, there is a land grab going on. whoever can get the most market share–wins. there’s an old rule of thumb from davidow who ran intel’s marketing during their high growth phase. having at least 30% of market share leads to consistent profitability in most niches. at that point, you can influence what happens. until you get to that point, you’re a commodity vendor. so while it can be a bit abstract, getting a strong footing in a niche will help establish you as a player. if you’re in a niche where this is happening, suddenly paying for growth has whole new meaning to investors. you only need to be a little bit better to beat out the competition, after all. the pre-emptive strike is similar to the land grab, but more defensive. let’s say you are a cheeky bootstrapper. you enter a market adjacent to niches already inhabited by companies with deep pockets. you’ll be at a loss when they decide to enter. for example, google entered the search market, knowing there were a lot of well-funded competitors at the time. yahoo, lycos, and altavista to name a few. moreover, there were big tech players like microsoft who had kind of missed the boat, but still had a lot of money. they could catch up quickly if needed. think bing. if google had tried to bootstrap their way into the market, despite having better technology, they could have lost. instead, they got funding. they built their technology to be completely scalable, while building up goodwill with users. then, after 6 years of funded growth, they finally introduced advertising to monetize the growth. in 2004, they launched adwords. last but not least, there’s the cash flow shortfall. this is more common in tech companies that combine hardware with rapid scaling. in essence, though the same financial problem happens across the sector. there’s a long list of well known companies which blew up, despite having a sales growth trend: osbourne, spectrum. that’s right. high growth, high sales, high profits, yet low cash inflows. if there is a long time gap between a sale and getting cash, the company won’t have enough cash to fund operations. scaling their operations becomes impossible without that. you may need an exponentially growing staff to service your exponentially growing revenues. you need inputs like parts for a hardware company–also at an exponentially growing pace. unlike in software, manufacturing at scale is complicated and costly. should you think this is a throwback issue from the 1970s, what about the internet of things? what about hardware startups today? so there you have it. five legit reasons to raise money for your startup. if you want to get on that path, you’re much better off using the lean startup approach. don’t take external money, if you don’t need it. stop selling yourself (and your business idea) short. validate your idea. with launch tomorrow , you can be certain that you’ve proven people want to buy what you’re selling. or thinking of proposing. or building. build the right product. make sure you can acquire customers profitably. then get funding. and break out the bubbly.

The software development life cycle is an extremely intensive process for developers and quality assurance professionals alike. If even one element is neglected, it can delay project schedules and affect user performance. Security is one aspect that must be built in from the inception of any app, and here are a few reasons why: Breaches can cost your business Let's say that an organization uses its application to order and manage inventory, payroll and other operational needs. If a malicious entity were to access this information, it could easily make fraudulent transactions, costing the company more than what was intended. Not to mention it will create a massive headache to set the record straight. TechTarget contributor Peter Gregory noted that this can happen when programs lack audit trails and processes required for secure purchasing. By building in this functionality early on, this type of situation can be avoided, allowing organizations to retain customer trust and money. "Organizations that fail to involve information security in the life cycle will pay the price in the form of costly and disruptive events," Gregory wrote. "Many bad things can happen to information systems that lack the required security interfaces and characteristics." Access to confidential data can be damaging If a business aims to use an app for information sharing and availability, protection must be at the forefront of this project throughout its life cycle. While some data may not be as costly to leak, the loss of confidential reports and documents can severely affect the organization's ability tofunction. QA teams must ensure that security practices are implemented and built upon constantly. TechTarget contributor Nick Lewis noted that firewalls and traditional methods will not be enough to keep targeted attacks at bay. Instead, testing the app for insufficient process validation, abuse of functionality, weak password recovery validation and information leakage will be critical toguarding the program. Analyze initial risk before jumping in One SDLC security practice to observe is a primary risk assessment before the start of a new project. Not all applications are equal, which means each program will be labeled with a different risk level. Some software will be publicly accessible, whereas others will be more business-critical and involve processing sensitive data. These uses will largely determine how much risk would be involved with a breach on such activities. This information will give QA teams a clear picture of the security roadmap needed, and can be implemented. "Doing the preliminary risk assessment to establish the need for the system helps identify any security show stoppers before too much time and effort goes into the next SDLC phases," a SANS white paper stated. "It also gets the design team thinking about security issues early in the design process." Cyberattacks and malware in the headlines have made security more prominent than ever before. By building in protections early in the SDLC, QA teams can ensure that they will be better able tohandle these threats without interruptions to regular business activities.

For many organizations, it seems like cyberattacks can come from anywhere, at any time. This sense is heightened by the number of endpoints in play that could be vulnerable to threats. Quality assurance teams must ensure that they have the data on hand to keep these risks at bay. By gathering information on current dangers, companies can better understand the attack surface and establish safeguards. Breaking down elements in play The attack surface contains all possible vulnerabilities - known and unknown - that may exist across your infrastructure, and sums up your risk of exposure. While the attack surface may seem like one big scary entity, it's actually made up of several parts. Tripwire broke considerations down into software, network and human attack surfaces to make this large picture easier to manage. QA professionals should approach the attack surface this way in order to ensure that all aspects are accommodated for rather than being overwhelmed by the big picture. Everything from coding to devices and human error must be considered when gathering information and preparing for potential threats. Analyze data and act on it Testing results can be a critical indicator of what types of vulnerabilities may be present within a program. The Open Web Application Security Project noted that an attack surface analysis will help QA and developers better understand what they're up against and build in security accordingly. During this evaluation, they must determine high risk areas of code, what functions should be reviewed for defects and when the attack surface has changed. This last consideration will be especially critical as further tests and adjustments will be needed to secure the software. Anything that an organization does could affect the attack surface, which means that it will have to be constantly monitored. QA teams need to ask what's changed, how it's different from before and what potential holes were opened in the process. This will help keep the attack surface visibly mapped out, making it easy to strategize how to protect the business, its employees and customers. Reduce the noise While a breach is certainly possible, that doesn't mean it should be easy for attackers to gain entry into business systems. Organizations can reduce their attack surface by decreasing the amount of noise within their infrastructure. Accuvant pointed out that doing this will reduce an attack's operating surface, minimizing the likelihood of malicious access. QA teams can use tactics like configuration management, exploit analysis, patching, sandboxing and secure application development to effectively reduce or eliminate the impact of a vulnerability. "Integrating these strategies into your security program make it much harder for exploits to attack your organization's systems," Accuvant stated. "By reducing your adversaries' operating surface, you are effectively limiting their attack surface." The threat of a vulnerability is a very real concern for businesses. By gathering information on what types of attacks are becoming prevalent and understanding how they can affect company software, QA teams can prepare for these risks and protect their users from the growing attack surface.

Introduction Continuous integration is a practice that helps developers deliver better software in a more reliable and predictable manner. This article deals with the problems developers face while writing, testing and delivering software to end users. Through exploring continuous integration, we will cover how we can overcome these issues. The Problem First, we will take a look at the source of the problem, which lies in the software development cycle. Next, we will cover some of the change conflicts that can take place during that process, and finally we will explore the main factors that can make these problems escalate, followed by an explanation of how continuous integration solves these issues. The Source of the Problem Let's take a look at what a traditional software development cycle looks like. Each developer gets a copy of the code from the central repository. The starting point is usually the latest stable version of the application. All developers begin at the same starting point, and work on adding a new feature or fixing a bug. Each developer makes progress by working on their own or in a team. They add or change classes, methods and functions, shaping the code to meet their needs, and eventually they complete the task they were assigned to do. Meanwhile, the other developers and teams continue working on their own tasks, changing the code or adding new code, solving the problems they have been assigned. If we take a step back and look at the big picture, i.e. the entire project, we can see that all developers working on a project are changing the context for the other developers as they are working on the source code. As teams finish their tasks, they copy their code to the central repository. There are two scenarios that can take place at this point. The code in the central repository is unchanged The code is the same as the initial copy. If this is the case, things are simple, because the system is unchanged. All the ideas we had about the system still stand. This is always the case if you are the only developer working on the application and if you have finished your work before the other members of your team. Either way, things are looking good for you. The system you have created and tested can be delivered to users without additional changes. The code in the central repository has changed The second scenario is that the application you have been working on has changed, and you discover this at the point when you try to copy your code over to the central repository. Changes in the code may or may not be in conflict with the ones you've made. If there are conflicts, you need to resolve them in order to be able to successfully deliver your code to the users. In this case, things could get complicated. Next, we'll explore the types of conflicts that can happen and what you may need to do to resolve them. Change Conflicts There are several types of change conflicts that can occur when integrating code. Here are some of the most common ones. We'll start with the simplest scenarios, and gradually explore the more complex ones. The implementation details have changed - You refactored a method, but so did the developer that has already integrated their code into the central repository. The behavior of the method is the same in all three implementations. You will need to pick the version that will stay, and remove the other implementations. You can even come up with a fourth implementation. This is a simple type of conflict, which you can usually resolve within a few minutes. The APIs you have been relying on have changed - For instance, the behavior of a certain method has changed. This could affect your code in a number of ways — from minor changes that you might need to make, to major structural changes. There is no silver bullet in such cases. You will need to carefully study the changes and make all the fixes. An entire subsystem of the application behaves in a different way - in such cases you will almost certainly be facing a partial, if not a full rewrite of your solution. If this is the case, you will probably need to speak with all the developers working on the application, because such a significant change should not happen without letting the rest of the team know about it. These and a number of other issues could come up, caused by various factors. Different versions of frameworks, libraries, databases are another potential source of conflicts. Once you have updated your code so it can be compiled or interpreted, you also need to remember to repeat all the tests that you have previously ran. These examples show that the amount of work needed to solve a problem that was initially assigned to a developer can easily double. Escalating Factors Here are some of the main factors that can make these problems escalate. The size of the team working on the project. The number of changes that are being pushed back into the main repository is proportional to the number of people on the project. This makes the process of integrating code into the main repository significantly harder. The amount of time passed since the developer got the latest version of the code from the central repository. As time passes, other people working on the same project are integrating more and more of their work, and changing the context in which your code needs to run. Sometimes the changes in the main repository are so big that it's easier to do a complete rewrite of your solution. A large number of changes in the system make integration events more complex and can have a huge effect on the productivity of the team. Such situations are even referred to as "integration hell". This process has a number of other negative consequences for your business. Testing and fixing bugs can take forever. Your releases are running late. Teams are stressed out because of long and unpredictable release cycles, and morale deteriorates. Solution: Integrate Continuously The solution to the problem of managing a large number of changes in big integration events is conceptually simple. We need to split these big integration events into much smaller integration events. This way, developers need to deal with a much smaller number of changes, which are easier to understand and manage. To keep integration events small and easily manageable, we need them to happen often. A couple of times a day is ideal. The practice of doing small integrations often is called Continuous Integration. The idea is simple, but at the same time it often appears to be impossible to implement in practice. This is because changing the process requires us to change some of our own habits, and changing habits is difficult. The Practice of Continuous Integration In order to avoid the previously described issues, developers need to integrate their partially complete work back into the main repository on a daily basis, or even a couple of times a day. To accomplish this, they first need to pull in all the changes added to the main repository while they were working on the code. They also must make sure that their code will work once it is integrated into the main repository. The only way to ensure this is to test every feature of the application. What first comes into mind when we start considering continuous integration is that the developers would need to spend half of their time every day testing the code in order not to break the code in the main repository for everyone else. This is why the prerequisite for continuous integration is having an automated test suite. Automated tests take away the burden of the manual, repetitive, and error-prone testing process from the developers. They also make the entire testing process much quicker. A computer can replace hours of manual testing with just minutes of automated testing. Behavior-driven and test-driven development are techniques that help developers write clean, maintainable code while writing tests at the same time. Testing techniques are out of the scope of this article, and you can read more about them in other articles on Semaphore Community. Tests make sense only if they are executed every time the source code changes, without exception. A continuous integration service such as Semaphore CI is a tool which can automate this process by monitoring the central code repository and running tests on every change in the source code. Apart from running tests, they also collect test results and communicate those results to the entire team working on the project. The result of continuous integration is so important that many teams have a rule to stop working on their current task if the version in the central repository is broken. They join the team which is working on fixing the code until tests are passing again. The role of a continuous integration service is to improve the communication between developers by communicating the status of a project's source code. How to Adopt Continuous Integration Continuous integration as a practice makes a big contribution to improving the development process, but also calls for essential changes in the everyday development routine. Adopting it comes with challenges that are easy to overcome if the process is introduced gradually. One of the biggest challenges teams face is the lack of an automated testing suite. A good recipe for overcoming this situation is to start adding automated tests for all new features as they are being developed. At the same time, the developer working on a bug fix should also work to cover the related code with tests. Whenever a bug is reported, the team should first write a failing test to demonstrate the existence of bug. Once the fix is created, the tests should pass. Over time, the automated tests suite gradually becomes more comprehensive, and the developers begin relying on it more and more. Adopting a continuous integration service to communicate the status of the tests to the entire team in the early stages of a project is also important, because it raises awareness of the project status among team members. Conclusion Introducing continuous integration and automated testing into the development process changes the way software is developed from the ground up. It requires effort from all team members, and a cultural shift in the organization. Big changes in the workflow are not easy to pull off quickly. Changes have to be introduced gradually, and all team members and stakeholders need to be on board with the idea. Educating team members about the practice of continuous integration practice and building the automated tests suite needs to be done systematically. Once the first steps have been taken, the process usually continues on its own, as both developers and stakeholders begin seeing the benefits of automated testing suites and the peace of mind that this practice brings to the entire team. Article originally posted on the Semaphore Community.

MongoDB 3.0.4 is out and is ready for production deployment. This release contains only fixes since 3.0.3, and is a recommended upgrade for all 3.0 users. Fixed in this release: SERVER-17923 Creating/dropping multiple background indexes on the same collection can cause fatal error on secondaries SERVER-18079 Large performance drop with documents > 16k on Windows SERVER-18190 Secondary reads block replication SERVER-18213 Lots of WriteConflict during multi-upsert with WiredTiger storage engine SERVER-18316 Database with WT engine fails to recover after system crash SERVER-18475 authSchemaUpgrade fails when the system.users contains non MONGODB-CR users SERVER-18629 WiredTiger journal system syncs wrong directory SERVER-18822 Sharded clusters with WiredTiger primaries may lose writes during chunk migration 3.0 Release Notes | Downloads | All Issues As always, please let us know of any issues. – The MongoDB Team

There are lots of good articles today. In the development section, Luke Wagner talks about WebAssembly and the companies that will be involved in the new initiative. Even though the large vendors are all playing nice for now, I expect to see performance comparisons well before any of them make it available to the public. On Both Sides of the Table, Mark Suster talks about doing less more often. Sometimes it is about focus and sometimes it is about not doing what everyone else is doing. As always, enjoy today’s items, and please participate in the discussions on these sites. Startups, Career and Process 8 secrets to succeeding in product management | Atlassian Unicorns | Stratechery by Ben Thompson 4 Common Mistakes Developers Make When Estimating | Javalobby Modern Code Review Practices Are More Than Finding Software Bugs | Javalobby The most important skill in software development | John D. Cook On Interviewing Software Engineers | ZDFS Do Less. More. | Both Sides of the Table Design and Development Splat goes Ruby | Firmafon Developers Blog WebAssembly | Luke Wagner’s Blog Practical Persistence in Go: SQL Databases | Alex Edwards How to monitor a Java EE DataSource | Vlad Mihalcea Manifold.JS Builds Hosted Web Apps on Android/iOS/Windows | NOUPE Organisation Pattern: Trunk Based Development | Javalobby Injecting Kubernetes Services in CDI managed beans using Fabric8 | Java Code Geeks Creating a Web App From Scratch Using Python Flask and MySQL: Part 2 | Tuts+ Code Tutorial Encapsulation | The Programmer’s Paradox Concurrency, Performance and Scalability Mr. Batch and the Quest for the right Threading Profile | Javalobby AI, Machine Learning, Research and Advanced Algorithms Inceptionism: Going Deeper into Neural Networks | Google Research A query complexity breakthrough | Shtetl-Optimized Levenshtein automata can be simple and fast | Jules Jacobs Big Data, Visualization, SQL and NoSQL Traded animals | Flowing Data Infrastructure, Operations and DevOps Does DevOps Reduce Technical Debt – or Make it Worse? | Building Real Software Link Collections Double Shot #1514 | A Fresh Cup Dew Drop – June 18, 2015 (#2037) | Morning Dew

I’ve been questioning my principles lately. One that’s been troubling me is a principle behind the Agile Manifesto: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” I always read this as “don’t start working late when things get busy”. I worked in a company that were really good at practising this. They almost never worked late. Quality was exceptional, tests many, bugs rare. Releases could be sent to customers whenever they need. Is never working late always the best policy? Applying pressure to a team, to deliver more before a deadline is a more common scenario. Rather than focussing the team on what’s important it can induce a state of panic. People are encouraged to stop thinking and “do” faster. Stupid busy culture emerges. A culture where working late is expected and results in a death spiral of poor quality. You’re always far away from a release. This seems very common and a difficult mindset to unravel, but are there more positive reasons to work late? I see people working late when they’ve become passionate about the work they’re doing. If they’re equally passionate about quality is this something I could accept or even encourage? Well yeah, I never want to discourage passion. If they knock off early the next day to get some well earned rest I’m all for that too. But is this passion hiding a more worrying truth? I see devs working late because they know the’re heading down a path that the rest of the team would freak at, but they’ve invested so much in it they don’t want to stop. When the guy or gal staying late doesn’t want to tell you why, it’s time to suggest the pub or attending a local meetup group might be a better alternative. So yeah I’m comfortable with people working out of hours if it’s because they’re passionate about what they’re doing. I worked with one dev who would work on experiments whilst his wife watched EastEnders. He’d join us the next morning excited about what he had to show. But it was always an experiment and we’d usually sit down together and re-write before committing it. Work done for the team should be done with the team.

The Three Elements of an Effective Strategy A product strategy is a high-level plan that helps you realise your vision or overarching goal. It describes who the product is for and why people would want to buy and to use it; what the product is and why it stands out; and what the business goals are and why it is worthwhile for your company to invest in it, as the following picture shows. The market describes the target customers and users of your product, the people who are likely to buy and to use it. The needs comprise the main problem your product solves or the primary benefit it provides. Think of a product like Google Search or Bing that solves the problem of finding information on the Internet. Compare it to a product like Facebook that allows you to stay in touch with family and friends. The key features and the differentiators are those aspects of your product that are crucial to address the main problem or create the primary benefit and that make people choose it over competing offers. Don’t create a mini backlog or a wish list. Instead focus on the three to five key aspects that make people buy and use the product. Take, for example, the first iPhone with mobile Internet, iPod-like digital music player, and touch screen as its key features; or the Google Chrome browser with its focus on speed, safety, and simplicity. The business goals capture how your product is going to benefit your company. Is it going to generate revenue, help sell another product or service, reduce cost, or increase the brand equity? Being clear on the business goals allows you to select the right key performance indicators (KPIs) and to measure your product’s performance. Take the iPhone and the Google Chrome browser mentioned earlier. While the iPhone currently generates the largest portion of Apple’s revenue, the Chrome browser does not earn any money for Google. But it allows the company to control the way people access the Internet and it has reduced Google’s dependency on third-party browsers such as Mozilla’s Firefox and Microsoft’s Internet Explorer. Both are important business benefits. You can capture your product strategy with the Product Vision Board, a simple yet effective tool shown in the following picture. You can download it from romanpichler.com/tools/vision-board or by clicking on the picture below. The Product Vision Board above captures the vision at the top. The four sections underneath it describe the strategy. The questions help you provide the right information. You can find more information about the tool in my post “The Product Vision Board”. Strategy Focus and Inflection Points The product strategy is not a static, fixed statement or document that you create for a new product. It changes as your product grows and matures. The following picture shows the product lifecycle with four key events: launch, product-market fit, rejuvenation, and end-of-life. he strategy for a new product should first help you get to launch, then achieve product-market fit (PMF), and finally sustain the growth of your product. Think, for instance, of the changes Apple has made to the iPhone since its launch in 2007 to keep it attractive and preserve its growth, from adding apps to changing the its size. Once the growth starts to stagnate you have reached another strategic inflection point: You either revitalise your product, for instance, by rejuvenating it or taking it to a new market, or you let it mature and eventually decline and die. To use the product strategy to proactively manage your product, you should review and adjust it on a regular basis – I recommend once a quarter as a rule of thumb. The Product Strategy in Context If the product strategy describes the key elements required to develop a success product as I suggested above, then where are the vision, the product roadmap, and the business model? The following picture shows how I relate the four artefacts. I view the vision as the ultimate reason for creating the product that describes the positive change your product should bring about as I describe in more detail in my post “8 Tips for Creating A Compelling Product Vision”. If you think of the strategy as a path to the vision, then the vision guides the strategy. Say I want to create a health app that helps people become aware of what and how much they eat. The vision could be to help people eat healthily, and the strategy might be to create an app that monitors the food intake. But that’s not the only way to attain my vision. If it turns out that the app is not a great idea, I could pivot and write a book on healthy eating, for instance, while still following my vision. As the picture above shows, I view the product strategy as an input for the product roadmap. The roadmap states how the strategy is implemented and describes how the product is likely to grow. The two work in tandem, as I describe in my article “10 Tips for Creating an Agile Product Roadmap”. Similarly, I like to derive the business model from the product strategy. A compelling value proposition and a large enough market is at the heart of every business model. It therefore makes sense to get the strategy right before you worry about the marketing and sales channels, the cost of acquisition, electing the right partners and suppliers and other business model aspects. Learn More You can learn more about creating an effective and valid product strategy by attending my Product Strategy Training Course. Please contact me for teaching the workshop onsite and for delivering it in form of an interactive webinar.

This book helps readers build successful games with the Unity game development platform. You will use the powerful C# language, Unity's intuitive workflow tools, and a state-of-the-art rendering engine to build and deploy mobile, desktop, and console games. Unity's single codebase approach minimizes inefficient switching among development tools and concentrates your attention on making great interactive experiences. Available as both a print book and e-book download from the publisher's website: http://www.manning.com/UnityinAction (You'll need to know how to program, in C# or a similar OO language. No previous Unity experience or game development knowledge is assumed.) Joe Hocking is a software engineer specializing in interactive media development. He works for Synapse Games and teaches classes in game development at Columbia College Chicago.

robert annett wrote a post titled diagrams for system evolution where he describes a simple approach to showing how to visually describe changes to a software architecture. in essence, in order to show how a system is to change, he'll draw different versions of the same diagram and use colour-coding to highlight the elements/relationships that will be added, removed or modified. i've typically used a similar approach for describing as-is and to-be architectures in the past too. it's a technique that works well. although you can version control diagrams, it's still tricky to diff them using a tool. one solution that addresses this problem is to not create diagrams, but instead create a textual description of your software architecture model that is then subsequently rendered with some tooling. you could do this with an architecture description language (such as darwin ) although i would much rather use my regular programming language instead. creating a software architecture model as code this is exactly what structurizr is designed to do. i've recreated robert's diagrams with structurizr as follows. and since the diagrams were created by a model described as java code , that description can be diff'ed using your regular toolchain. code provides opportunities this perhaps isn't as obvious as robert's visual approach, and i would likely still highlight the actual differences on diagrams using notation as robert did too. creating a textual description of a software architecture model does provide some interesting opportunities though.

Hear the opinion of a Spring and JavaEE developer that wants to share his thoughts on this epic Spring vs JavaEE debate. Covers business and technical aspects.

Need to replace all occurances of a pattern text and replace it with a captured group? Something like this in Java works nicely: String html = "myurl\n" + "myurl2\n" + "myurl3"; html = html.replaceAll("id=(\\w+)'?", "productId=$1'"); Here I swapped the query name from "id" to "productId" on all the links that matched my criteria. But what happen if I needed to pre-process the captured ID value before replacing it? Let's say now I want to do a lookup and transform the ID value to something else? This extra requirement would lead us to dig deeper into Java RegEx package. Here is what I come up with: import java.util.regex.*; ... public String replaceAndLookupIds(String html) { StringBuffer newHtml = new StringBuffer(); Pattern p = Pattern.compile("id=(\\w+)'?"); Matcher m = p.matcher(html); while (m.find()) { String id= m.group(1); String newId = lookup(id); String rep = "productId=" + newId + "'"; m.appendReplacement(newHtml, rep); } m.appendTail(newHtml); return newHtml.toString(); }

Learn about using the microservice architecture pattern to build microservices and API gateways--compared to the usage of monolithic application architecture.

I want to share a little utility we wrote, which is basic, but can be quite useful. If you have a big environment with lots of instances, EBS volumes and EBS snapshots you sometime lose your grip and control. I mean specifically in terms of "Is my data protected?" or "Do I have recent enough snapshots to recover my instances, if needed." Our customers, using Cloud Protection Manager, typically don't need to worry about it, as they have a complete control over their EC2 backup operations. However, many EC2 users may find it useful to get a report that will be able to tell which instances and volumes don't have recent enough snapshots. This utility, which is a python script, creates a report as a CSV file which gives a list of EBS volumes, with almost all details, including which instance volumes are attached to, and tells how many snapshots there are on each volume, and when the oldest and newest snapshots were taken. Since it's in CSV format, it's easy to open it with a spreadsheet (like Excel) and then color the lines according to values (click on picture to see). You can make volumes that have too few snapshots or don't have a recent enough one to be colored red, ones with more but stilll not enough can be colored yellow etc... If you go a bit deeper you can even find out which instances have "red" or "yellow" volumes, to be able to identify them as "unprotected." For each volume the following details are given: region, volume id, volume name, volume type, iops value, size (GiB), snapshot the volume was created from, instance the volume is attached to, device name, whether the volume is encrypted, number of EBS snapshots on this volume, time and id of oldest snapshot, time and id of newest snapshot. The script is written in Python and will work on Linux or Windows, as long as Python 2.7.3 or newer (not Python 3) is installed, and the “boto” library is installed as well (at least 2.31.1). Instructions to install boto can be found here: http://boto.readthedocs.org/en/latest/getting_started.html#installing-boto (Or simply download it from https://pypi.python.org/pypi/boto then open the tarball, go in the installation folder and type: python setup.py install) The script is well documented. It can get the AWS credentials from command line or set defaults in the script itself. If the script is run from within an instance that has a proper IAM role, then no credentials are needed at all. ebs-report.py README.txt >python ebs-report.py --help usage: ebs-report.py [-h] [--regions REGIONS] [--access_key ACCESS_KEY] [--secret_key SECRET_KEY] --file FILE Creates a CSV report about EBS volumes and tracks snapshots on them. optional arguments: -h, --help show this help message and exit --regions REGIONS AWS regions to create the report on, can add multiple with | as separator. Default will assume all regions --access_key ACCESS_KEY AWS API access key. If missing default is used --secret_key SECRET_KEY AWS API secret key. If missing default is used --file FILE Path for output CSV file Example: python ebs-report.py --regions us-east-1 --access_key AKIAIXXXXXXXXXX3N32Q --secret_key UGSYXXXXXXXXXXXXXXBf0bS/S+OwnA2GrJ0MOY4Y --file d:\my-ebs-report-July-2014.csv README file - http://www.n2ws.com/images/code/ebs-report/README.txt

Foreign key references can be found across the database with a simple Microsoft SQL Server code. This code will work between the tables to get the keys.

Learn why 12 Factor Application Patterns, Microservices and CloudFoundry matter when trying to change the way your product is produced.

Get familiar with testing encoders/decoders in Netty, an asynchronous event-driven network application framework for developing protocol servers and clients.

While working on different web projects I have accumulated a large pool of tools and services to facilitate the work of developers, system administrators and DevOps One of the first challenges, that every developer faces at the end of each project is backup configuration and maintenance of media files, UGC, databases, application and servers' data (e.g. configuration files). Nowadays, there are a lot of solutions to make a snapshot backup of the entire server, and I decided to make a list of most convinient and really useful tools and services. rsync - http://linux.die.net/man/1/rsync Rsync is a fast and extraordinarily versatile file copying tool. It can copy locally, to/from another host over any remote shell, or to/from a remote rsync daemon. It offers a large number of options that control every aspect of its behavior and permit very flexible specification of the set of files to be copied. It's a build in Linux tool. Real hardcore =) rsnapshot - http://rsnapshot.org/ rsnapshot is a filesystem snapshot utility for making backups of local and remote systems. Using rsync and hard links, it is possible to keep multiple, full backups instantly available. The disk space required is just a little more than the space of one full backup, plus incrementals. Depending on your configuration, it is quite possible to set up in just a few minutes. Files can be restored by the users who own them, without the root user getting involved. Stackoverflow users recommended it to me couple of years ago and I thinks that is a really good solutions, which unites the best from rsync and Linux filesystem. Snapper - http://snapper.io/ Snapper is a tool for Linux filesystem snapshot management. Apart from the obvious creation and deletion of snapshots, it can compare snapshots and revert differences between snapshots. In simple terms, this allows root and non-root users to view older versions of files and revert changes. Allows you to configure schedule for the backups, automatically deletes old snapshots. The only sad thing is that Snapper has no updates since 2014. backup2l - http://backup2l.sourceforge.net/ backup2l is a lightweight command line tool for generating, maintaining and restoring backups on a mountable file system (e. g. hard disk). The main design goals are are low maintenance effort, efficiency, transparency and robustness. In a default installation, backups are created autonomously by a cron script. The script, that I've found on sourceforge and even used on couple of my projects 5 years ago. But it is not being updated since 2009. FlyBack - https://www.linuxlinks.com/flyback/ FlyBack is software for system backup and restore, which offers similar functionality to the Mac OS X Leopard's Time Machine. Linux has almost all of the required technology already built in to recreate it. FlyBack is a snapshot-based backup tool based on rsync. It creates successive backup directories mirroring the files users want to backup, but hard-links unchanged files to the previous backup. Plenty of settings, mostly build for desktop computers, simple UI. TimeVault - https://wiki.ubuntu.com/TimeVault TimeVault monitors files for changes and takes snapshots after some user-specified delay. It is a simple front-end for making snapshots of a set of directories. Snapshots are a copy of a directory structure or file at a certain point in time. They use very little space for files which have not changed since the last snapshot was made, as they use hard links that point to existing backups. TimeVault makes all the work silently in background and is fully automated solution. Currently it gets no updates but it was a good solution when it just released. Box Backup - http://www.boxbackup.org/ Box Backup is an open source, completely automatic, on-line backup system. A backup daemon runs on systems to be backed up, and copies encrypted data to the server when it notices changes - so backups are continuous and up-to-date (although traditional snapshot backups are possible too). All backed up data is stored on the server in files on a filesystem - no tape, archive or other special devices are required. BitCalm - https://bitcalm.com BitCalm makes it easy for web developers to set up backup of applications on Linux servers just in one minute. It is SaaS for server backups. After installing python client user can manage backups for files and even databases in web-interface. Service provides Amazon S3 as a storage and allows users to connect their own storage for backups. All backups are incremental. Service is built for servers and supports all popular Linux based OS: Ubuntu, Debian, CentOS, ArchLinux. To let user be calm, service sends daily reports and notifications. BitCalm allows to manage multiple backups in a single account and user can restore the backup to any server added to service.