I have read the article and this thread with keen interest. I am curious to solicit community feedback on our choices as we faced the Node vs. Java choice in 2012. In particular, does our business ultimately suffer long term consequences by our stack choice? We think we ultimately have strong advantages vs. any competitor built using Node.JS, but the beauty of HN is that we can open up the thoughts for everyone to contribute.
I am the CEO and founder of Codenvy. We make SAAS developer environments, and have been working as a team since 2009. Starting in 2012, we recognized the limitations of our initial system and needed to rebuild the entire system from the ground up. We had three criteria: performance, security, and modularity (of our core base and an ability for ISVs / enterprise to plug-in their own customizations). We raised $9M in Jan 2013, so we now have big investors and aspirations equally large. Our target market is primarily enterprises and ISVs that build Eclipse plug-ins. Individual developers and consultants are a secondary audience.
We chose to go with a pure Java stack, after a careful evaluation of Node.JS vs. Java. We wanted to provide some of our thoughts, as we continually ask ourselves whether there are downsides to the approach we chose. For the record, we have competitors like Eclipse Orion and Cloud9 that are pure JavaScript / Node implementations, but we are - as far as I have seen - the only Java implementation in our market.
Our team is currently 40 people, with 35 or so in R&D. Our engineers have experience with Java, Scala, JavaScript, AngularJS. Prior to this project, most engineers were working on server systems for content and document management firms. The hard stuff: sync, versioning, correlation, and so on. As for myself, my career started as a Java engineer in the 90s, but for the most part have been hands off as a technologist for a decade. My skills may have faded, but as a CEO, I am conversant.
We did 2 prototypes on Node.JS where the client and server were combined systems. We ran a battery of performance tests and did conclude that we could probably run a large scale system on fewer physical nodes with Node.JS than with Java, but the gains were not enough to justify the choice.
Our long term architecture was different from our competitors. Most SAAS dev environments provision each user / group their own VM, give you root access, and let you control that system. We chose an approach that would optimize overall system density by by offloading builds, debugs, and editing onto separate clusters. User environments will be virtualized and routed to the appropriate cluster on-demand. The user will feel like they have a personal VM, but our elvish helpers route traffic between the nodes across performance queues.
After offloading LDAP (for identity), event / log management (for analytics), and cloud administration, the only core systems left was our API services (account / builder / runner / auth) and editing. These core systems would be subject to heavy iterative development, and Node's architecture could offer higher density of requests / users than Java, but by our tests the comparison was 10-20% difference, not 300%.
By way of scaling, for every 10,000 concurrent developers, we average 20 editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5 builder nodes (CPU constrained). A similar TS / VDI implementation would require nearly 5,000 nodes of the same shape / size to service the same population.
So, we saw a disadvantage to Java as we could have reduced our editing node even further. But we chose Java because:
a) The library selection. Broad and mature. In particular, it's data structures, file management, REST services.
b) GWT. This library gave us cross-browser portability of code written in Java.
c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in developers and saw the Orion project as optimized for Web dev, leaving a gap in Eclipse. We saw it as a business gamble that Eclipse devs who needed to move their plug-ins would find a pure Java plug-in architecture that was similar to RCP more attractive than a newer (but have to learn new tech & rewrite) approach.
d) Our history. We did a straw poll of our engineers before we started. We asked them if they felt that they would rather do Node or Java, and 75% said that they would enjoy Java more. When asked why? They had tool familiarity, were confident in the maturity of maven, and better job prospects. This last one completely surprised me.
e) JVM. The number of optimizations of the JVM would give us advantages for enterprise deployment. We built our system to be automatically installable on-premises. We do so with Puppet, but recognized that we would be encountering many IAAS and PAAS standards internally. Enterprises had security and performance tested the JVM, so we saw an opportunity to win hearts and minds of system admins, datacenter architects, and security specialists by our choice of architecture.
So, we carried forward. Since we started working on our next generation architecture, we have focused hard on the best practices associated with agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each focused on a different aspect of our stack. We are able to release any Jira issue at any point in the day. Each team can push into acceptance, staging or production without coordinating with the other teams. At the same time, we have achieved modularity and a rapid development tempo. While we haven't released our new system to the market yet, we find that the performance of the environment is similar to a desktop environment, and it scales cleanly with simulated load tests. We have also been able to give out our SDK (github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse plug-in developers, who are able to code, build, test, integrate, and publish their plug-ins without complicated dependencies to our core team. Their feedback was that the port of their plug-in took about 1/2 the time of the original development. And there is no real way to estimate what the effort would be to do the same in a Node-based offering like Orion.
What we can't measure is whether our competitors are able to release faster & more functionality than we are. It seems like a crap shoot. One other variable we can't account for is the cost to maintain legacy. The system we have Codenvy.com is legacy for us, and will be retired in Q3. We have to continually allocate 3-5 people to work on bugs, special partner projects, or other related items to keep that system live while we also work to roll out the new system. We know this is a drag, and some of our engineers think we may more than double our productivity once we consolidate to a single architecture. I am a bit skeptical at that - but I find that it's unwise to disagree with my engineers. I tend to lose.
So at this point, we feel like we made the right choice. But time will tell - we begin selling our enterprise offering earnestly once we ship our new system in Q2.
I thought CodeBox was using the ACE editor as part of their system like Cloud9. And I believe Orion and Codenvy (my company) use CodeMirror. Looking forward to trying out Atom. I can see many advantages already of it as an editor.
Here is an unusual one. I have followed this similar strategy for the past 4 years on a more aggressive plan, and have returned 36%, 28%, 33%, and 6% for the past four years. The strategy heavily shorts the market, and goes partially long in a way that 99% of the time generates reliable, steady returns, and in the 1% extreme cases offers adjustment techniques to handle what the market is giving you. The aggressive nature of my approach causes the high volatility in the returns, but a much safer approach can be taken which would have nearly a 99.9% assurance of the 5%.
Sell calls and puts on the SPX index on a weekly basis. You need to generate $1K of income each week. On an account that uses Portfolio Margin at a broker like IB, $1M would allow you to open nearly 100 contracts on both the call and put side.
To appropriately manage risk, at the SPX trading at $1840, you could open up 50 calls at $1935 with 1 week to expiration for $.05. This will generate $250 of income as long as the stock market doesn't climb >6% in a single week. This has happened in the past, but only after the market has crashed the day before. 3% climb in a single week on a broad based index would be a once in a generation blue bird event, so the risk on this money is incredibly low. And even if the market did climb up steeply suddenly, there are many options adjustment techniques where you give yourself more time, generate more income, and create additional buffer to stay away from the market.
By selling 50 calls for $.05, you still need to generate $750. You do this by selling puts on the offsetting side. Markets have a tendency to crash downward, so you want to sell far fewer contracts and buy some insurance for the rare case of a market crater situation. You could sell 15 puts at $1730, again 6% below where the market is currently. A 6% drop in a single week is a rather rare event. And to hedge against a flash crash event, you buy $.10 puts at $1515. In the rare event that the market crashed or the market did drop >5% in a single week, then the same sort of adjustment techniques available in the call scenario exist here. There would be a side benefit of while you have to adjust the trades to wait for the profit, the market's volatility would have skyrocketed and the potential to gain more money is really high. Essentially, you could make your $1,000 of income by being 10-15% away from the market with high volatility instead of being 6%.
This technique requires weekly trades to be opened, which is a bear. And you have to learn the adjustment techniques, but once understood and accounted for, things are pretty regular and consistent. There is a side benefit of these options being 1256 contracts in the US, so there is beneficial tax treatment. Even though your trades are 1 week long, 60% of the gains are long term cap gains treatment.
So this isn't entirely low risk, but in all of the scenarios where is a bond / stock mix, there is inherent market risk as well. Even bonds that payout 5% can drop in value, so the principal isn't $1M anymore. So finding a great balance is a lot of work.
Selling strangles on broad indexes is a type of diversification, just of a completely different nature.
I have a fairly involved white paper that I have drafted that outlines the strategy for anyone that wants to review it.
The Monaco project form Visual Studio is exciting. We (Codenvy) have tracked nearly 50 web-based editors that have emerged in the past 2 years. A few of them have transitioned into full businesses with venture backing. Most of them have remained side projects or experiments.
With Microsoft's project related to Monaco and their VP's statement in the TechCrunch article that this style of development is where the future is vectoring towards, this is the first major platform vendor that has indicated that they see these sorts of cloud environments as not only as supplemental to core development, but potentially displacements.
Of course, there are years of engineering ahead before cloud systems can offer true displacement, but some of the early adoption scenarios are getting well defined. We attempted to capture the market size and early adoption drivers of cloud browsers in this quora post.
are you estimating the market for such (Cloud-IDE) tools being currently $465M or did I misunderstood that - interesting when now the first key (legacy) development IDE providers (MS - VS) are moving towards that approach as well.
The size of the market in monetary measures depends upon how you define the market itself. If your definition are companies that provide Web-based editors or specifically IDEs with functionality specifically around edit / build / run / deploy, the market is very small today. But if you look at the broader cloud development market that includes code hosting, test, and some other functions that can sometimes be associated with IDEs, then that market is $465M and it's growing rather fast.
From looking at Codenvy's logs, about 3,000 of our recurring users access the system using a chromebook or tablet. It's only single digit % overall, but it's a number that is larger than we would have thought it would be.
I am the founder of Codenvy, a type of Web IDE that is more focused on enterprise apps. We have found that the value of cloud workspaces has been around instant access and centralized control (for groups of workspaces). So, it is possible to offer on-demand, temporary workspaces without login (some vendors provide that including Codenvy). It tends to be a vendor choice as to whether requiring authentication before gaining project access is important. Most vendors do require authentication as it allows for saving important properties, user configurations, and some security settings.
To see some of the use cases around why cloud IDEs are used over desktop IDEs, we have listed them on our site. https://codenvy.com/why/cloud-ide/. The early uses have been around scenarios where configuration / setup of desktop are burdensome: pair programming, hackathons, training events, or partner integrations. We have some demos with Google, Intuit, and WSO2 that show what IDE on demand might be like, but those are special case scenarios.
As for the concept of downloading the IDE itself. Some cloud vendors do offer offline mode, and packaged chrome apps which do give that very behavior. It's first inning sort of stuff, but it will be possible in the future to allow offline sync of the development experience. Some cloud providers offer both build / debugger runtimes, so downloading offline, means also having a way to synchronize the project's files, and the underlying infrastructure necessary to execute the code. In a pure Web app sense, where it's HTML / CSS / JavaScript, this is fairly easy. But if you need to have synchronized access to dependencies, libraries, or runtimes, then the challenges are more pronounced.
"Developers Spend 13 Hours/Week Administering Their Desktop.".
That seems like an awful lot, 2 days a week on "administering"? Is this real data from desktop IDE users, if so then this is clearly a huge problem. What kind of things are people spending the 13 hours on each week that is saved by moving to a Cloud IDE?
I could see overhead if developers were constantly swapping from project to project to fix bugs and each of those projects had different set ups in terms of where the source code was stored, how it was configured etc.
I can't speak for other companies/languages/setups but using one of Eclipse/Netbeans for Java with Maven and SVN/Git is pretty low overhead in terms of configuration for me. For PHP we use SVN, SublimeText and pre-defined build and deploy scripts, which also do not have many pain points.
Genuine question: where is the 13 hours spent each week?
It was a study done by 1200 engineers on LinkedIn and Electric Cloud. I think it was February 2013 when the results came out.
This does have a tendency to happen in various degrees in larger enterprise environments where configuration problems of the IDE and the systems you are building become costly to maintain. The way we think about it is that organizations have invested in DevOps technologies to automate the entire release process post-commit of the code. But that once the changes make their way out into complex staging / production environments, there are config + code changes that do not synchronize cleanly back into the developer's workspace. So, as the number of commits increases, and the size of the team increases, there are many more synchronizations that need to occur to keep development systems ready for the coders.
So the time suck shows up in mysterious ways:
1) Maintenance of the IDE install, especially with Eclipse which has had plug-in versioning & interoperability challenges at times.
2) Synchronizing configurations across teams, commits, and machines.
3) Collaborative / human costs, from the time spent in having large teams figure out the best way to operate & use their development workbenches consistently.
4) The environment problem, which is partly due to the production environment configuration is not exactly identical to what can be run on the desktop, so managing that in an automated way poses time issues.
I do imagine many people feel like the previous commenter, myself included. For cloud development many of us use vim for browser based stuff like this I love jsfiddle. I really felt it would have been beneficial to just let me see and use the product without signing up. The product is very niche and serves a very specific purpose. The reality is if I really liked the product and had intentions of using it I would have created an account. I saw the sign up page and left.
I have a couple of stories that I want to share. One of which has taught me a lesson about being too trusting.
I am both:
1) A venture partner (Toba Capital) where I manage existing investments, do diligence on potential new ones, and make decisions regarding how capital is allocated; and:
2) A founder / CEO (Codenvy), a development cloud with a browser IDE front-end, often times called a cloud IDE.
This article resonates with me as I can see the perspective from both sides of the coin. As a rule, in venture capital, myself and my firm does not sign an NDA. The basic rationale is that it's virtually impossible to resolve all of the potential conflicts that are associated with the NDA from both firms. So, we go with the basic principle is that we need to trust the people we are talking with and vice versa. Our reputations and history of deals / interactions are the best guide and we openly tell people up front that if there is information that is secret for themselves, they should withhold it until they have a chance to do background checks on us. In some cases, there are startups that are so secretive that we cannot infer anything at all, and we just have to politely decline and move forward.
A couple of interesting scenarios playing for me recently. I sit on the board of Sauce Labs, a cloud test company. But my venture firm recently inherited a stake in Smart Bear, a QA vendor where there are edges of competition. While neither vendor sees the other as competitive, the optics of the situation to an outsider could suggest otherwise. So in this case, we have opted to create a chinese firewall inside of Toba where I do not listen in on core data provided by Smart Bear, even though their CEO said this wasn't an issue.
Another scenario that came up recently was a referral to explore a pre-funded startup idea around making database querying easier for non-SQL expects. The referral was a warm one to the founder. We asked for the usual background information to make a surface area assessment. The input given was a very limited sales presentation with a couple screen shots and a few accompany statements from the founder that they presented to a VC and that the VC recited their entire pitch to them. And then that person stated they would only work with people who had their same vision. When probing for more thorough information, the founder became a bit squirrely, which is probably due to some sort of discomfort around sharing stuff. But there wasn't an NDA requested, and we could only conclude that maybe their claims of awesomeness were slightly exaggerated.
Now for the story around trusting too much. With my Codenvy CEO hat on in January we had recently closed our Series A for $9M in January. It was a great feeling as it took us over 6 months of raising to close it. And let me tell you, just because you a valley VC doesn't make it any easier to close your own firm's financing. Post funding we were looking at strategies for how we could grow faster. We came across a likely competitor that had 2 people part of the business and based in Europe that had raised a small amount of seed funding (<$300K). It was obvious to us that there was some great talent in the team and their focus on the market was complementary to our own. We felt that it would cause both companies to grow much faster if we could merge and join forces. They were interested and we all met together to discuss what a game plan might look like. Of course, in that conversation, we shared specifics around how we were envisioning the next 12 months to look like. We made an offer and they opted to pass. No big deal. But where we learned our lesson was that about 5 months later, this summer they released a number of features that were -- somewhat -- reflections of the vision we had shared with them, all the way down to them calling the features the same marketing brands we had ear marked. At the time, we felt foolish and anger around their ethics of the situation, and it was particularly irritating to our own engineers that they were beat in the market. There were many discussions around this, and it raises the question of how you discuss potential plans around an acquisition / investment, if you are afraid they may steal the ideas.
In the end, it's all good as we have learned some stuff:
1) The acquisition would have certainly failed. How could we have worked with people who have thin ethics?
2) We have subsequently released everything they heard from us, and our approach to everything is a) more mature, b) more scalable, c) better received. We learned that while they could take the surface area ideas, they haven't been able to exploit them to their true meaning the way they were intending.
3) Our engineers found a new form of competitive motivation that didn't exist before these - trusted - individuals decided to pawn some of their ideas. The entire culture, motivation and mindset within our (rather large) engineering office has developed into a killer instinct. And as a leader I find this trait as crucial to long term success. I am unsure if this killer instinct would have developed as quickly without this incident.
So, the issues in the article are real, and they show up when you least expect them. I think, going forward, I am just going to keep thinking about being truthful, keep my ethics high, and work with people who are the same. I'll sleep easy at night as a result.
I think that there's probably a difference between approaching potential customers or funders whose businesses are somewhat orthogonal to your own direction and approaching direct competitors or parties who have the competence to 'steal' your ideas.
If I'm working on something similar to you, it's probably a trivial thing to include your ideas in my product. But if I am doing something completely different, the cost of switching track to 'steal' your great idea is probably so high that it's not worth while.
Now of course there may be second order effects or you may misjudge someone else's direction. That's where you have to rely on trust and reputation. But I think that getting ideas out to people who may help and are unlikely to want to compete is essential - external feedback is what's likely to stop you from disappearing down the rabbit hole, so to speak.
I like your last paragraph very much - life becomes a lot simpler when you try to stay around people who act the 'right' way (whatever that may mean to an individual). It takes a lot of mental load off and gives you the freedom to do things of which you can be truly proud.
I'm not sure I agree, in the case of the latter story, that the other company was unethical. You contacted them, correct? In order to place them under an obligation of confidentiality, you needed to offer them some consideration in exchange for that obligation. It's not clear from what you relate here that you did that. I think you just flat screwed up, and your engineers' anger would have been more appropriately directed at you than at the other company.
Perhaps a fuller account would change the picture, but that's how it looks to me from what you've said here.
Yes, good points. There is some missing context. We did contact them, but I failed to point out that the conversation developed over a number of pre-cursor setup calls. And that before there were substantive acquisition talks, there was discussion between the parties on the general areas where each of our businesses were claiming strategic importance along with tacit acknowledgment to generally vector away from those segments. In our case, we provided deeper insights around the specifics of how we intended to pursue our unique strategy after the initial discussion.
With any acquisition or potential partnership with a company that has the potential to compete, whether on the edges or directly, there are unique challenges to figuring out what information you should share and at what time.
But the take away for us was that we had a reasonable expectation that this particular vendor would not behave this way based upon our pre-cursor discussions.
Thanks for sharing. The one difference I'd like to point out between this scenario and someone at idea stage is that you had a team together (resources to execute), and new $9 million to "play" with. Imagine if you went to those 2 in Europe and you were just getting started. They perhaps could have come into your market with investment money and beat you to market. This is why I think it's naivety whenever people say "ideas are a dime-a-dozen" or they themselves are unoriginal, uncreative and copy ideas relentless (and perhaps exactly) and that's a justification phrase for them to not feel guilty.
Good examples. I pretty much agree with all you say, but didn´t have live experience to support my ideas. I would also say that where you are located or the group you are talking to, is important.
I live in Spain and I pretty much could give away hundred of copies of our business plan, and no competitors are going to rise from that.
I think that even in SV I could pretty much give the general idea and I´ll bet that no competitors would rise either. At least not in the same form, execution surely would be different. Not because is a new idea, but because it´s not something you can hack in a month with some ruby gems, it needs some investment in coding, and even more effort on market development.
Execution and product vision is everything in startups, unless you are talking of a new feature in an established industry, AND talking to people related to the industry. That´s probably the place for an NDA.
Couldn't they just have copied those features later? Sure they might have been later to the market but pushing features out first doesn't mean you will win. I understand the anger and I absolutely think it's unethical but something like this will happen as long as the other party is untrustworthy. Situations like this are like a hand of poker sometimes you have all the information you need and you can move all in confidently, while sometimes you don't and you have to gamble a bit. You were understandably angry because you lost.
I am the CEO and founder of Codenvy. We make SAAS developer environments, and have been working as a team since 2009. Starting in 2012, we recognized the limitations of our initial system and needed to rebuild the entire system from the ground up. We had three criteria: performance, security, and modularity (of our core base and an ability for ISVs / enterprise to plug-in their own customizations). We raised $9M in Jan 2013, so we now have big investors and aspirations equally large. Our target market is primarily enterprises and ISVs that build Eclipse plug-ins. Individual developers and consultants are a secondary audience.
We chose to go with a pure Java stack, after a careful evaluation of Node.JS vs. Java. We wanted to provide some of our thoughts, as we continually ask ourselves whether there are downsides to the approach we chose. For the record, we have competitors like Eclipse Orion and Cloud9 that are pure JavaScript / Node implementations, but we are - as far as I have seen - the only Java implementation in our market.
Our team is currently 40 people, with 35 or so in R&D. Our engineers have experience with Java, Scala, JavaScript, AngularJS. Prior to this project, most engineers were working on server systems for content and document management firms. The hard stuff: sync, versioning, correlation, and so on. As for myself, my career started as a Java engineer in the 90s, but for the most part have been hands off as a technologist for a decade. My skills may have faded, but as a CEO, I am conversant.
We did 2 prototypes on Node.JS where the client and server were combined systems. We ran a battery of performance tests and did conclude that we could probably run a large scale system on fewer physical nodes with Node.JS than with Java, but the gains were not enough to justify the choice.
Our long term architecture was different from our competitors. Most SAAS dev environments provision each user / group their own VM, give you root access, and let you control that system. We chose an approach that would optimize overall system density by by offloading builds, debugs, and editing onto separate clusters. User environments will be virtualized and routed to the appropriate cluster on-demand. The user will feel like they have a personal VM, but our elvish helpers route traffic between the nodes across performance queues.
After offloading LDAP (for identity), event / log management (for analytics), and cloud administration, the only core systems left was our API services (account / builder / runner / auth) and editing. These core systems would be subject to heavy iterative development, and Node's architecture could offer higher density of requests / users than Java, but by our tests the comparison was 10-20% difference, not 300%.
By way of scaling, for every 10,000 concurrent developers, we average 20 editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5 builder nodes (CPU constrained). A similar TS / VDI implementation would require nearly 5,000 nodes of the same shape / size to service the same population.
So, we saw a disadvantage to Java as we could have reduced our editing node even further. But we chose Java because: a) The library selection. Broad and mature. In particular, it's data structures, file management, REST services. b) GWT. This library gave us cross-browser portability of code written in Java. c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in developers and saw the Orion project as optimized for Web dev, leaving a gap in Eclipse. We saw it as a business gamble that Eclipse devs who needed to move their plug-ins would find a pure Java plug-in architecture that was similar to RCP more attractive than a newer (but have to learn new tech & rewrite) approach. d) Our history. We did a straw poll of our engineers before we started. We asked them if they felt that they would rather do Node or Java, and 75% said that they would enjoy Java more. When asked why? They had tool familiarity, were confident in the maturity of maven, and better job prospects. This last one completely surprised me. e) JVM. The number of optimizations of the JVM would give us advantages for enterprise deployment. We built our system to be automatically installable on-premises. We do so with Puppet, but recognized that we would be encountering many IAAS and PAAS standards internally. Enterprises had security and performance tested the JVM, so we saw an opportunity to win hearts and minds of system admins, datacenter architects, and security specialists by our choice of architecture.
So, we carried forward. Since we started working on our next generation architecture, we have focused hard on the best practices associated with agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each focused on a different aspect of our stack. We are able to release any Jira issue at any point in the day. Each team can push into acceptance, staging or production without coordinating with the other teams. At the same time, we have achieved modularity and a rapid development tempo. While we haven't released our new system to the market yet, we find that the performance of the environment is similar to a desktop environment, and it scales cleanly with simulated load tests. We have also been able to give out our SDK (github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse plug-in developers, who are able to code, build, test, integrate, and publish their plug-ins without complicated dependencies to our core team. Their feedback was that the port of their plug-in took about 1/2 the time of the original development. And there is no real way to estimate what the effort would be to do the same in a Node-based offering like Orion.
What we can't measure is whether our competitors are able to release faster & more functionality than we are. It seems like a crap shoot. One other variable we can't account for is the cost to maintain legacy. The system we have Codenvy.com is legacy for us, and will be retired in Q3. We have to continually allocate 3-5 people to work on bugs, special partner projects, or other related items to keep that system live while we also work to roll out the new system. We know this is a drag, and some of our engineers think we may more than double our productivity once we consolidate to a single architecture. I am a bit skeptical at that - but I find that it's unwise to disagree with my engineers. I tend to lose.
So at this point, we feel like we made the right choice. But time will tell - we begin selling our enterprise offering earnestly once we ship our new system in Q2.
Looking forward to the discussion.