Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm working on Magento 1.9.3.7 and I want to understand if is a good idea to migrate to Magento 2 or not.
I summarized this differences :
Magento 2.0 is faster then Magento 1.x
Some significant changes in the structure of directory which reduces
the complexity of structure
New technologies and latest versions (example Php, Jquery etc)
Allows developer to setup automated test easily
Many features are now integrate to Magento 2
Improvements to checkout and other stuff
My questions:
There is any index to look up to decide when is a good moment to migrate to Magento 2?
There are any hidden issue I have to know before?
Someone ever try this migration? If yes do you see this big improvement?
All my modules (third parts & hand-written) will be obsolete?
Why Magento 1.x is still releasing new security updates if there is Magento 2?
I hope to listen to different experencies or solution to understand if is the right way.
Please if I said something wrong tell me.
Docs on Internet (differences) : https://gauge.agency/articles/the-differences-between-magento-1-and-magento-2-and-which-is-better/
Having worked extensively with both platform, I have to say that Magento Inc's reasons for upgrading to m2 are just silly.
Magento 2.0 is faster then Magento 1.x
This is not really true, right? Reasons why they say that M2 is faster is that it supports php 7.x and runs Varnish. To this, I say, so what? M1 does as well.
Community efforts like this one work like a charm: https://github.com/Inchoo/Inchoo_PHP7 (I'm in no way affiliated with Inchoo).
Edit: This is now even less true since M1 (as of 1.9.4) supports 7.2 without third party modules.
On the other side M2 has a semi working asset precompiling system, which keeps causing issues on every turn. Further more, it slows the development to such degree that M1 feels like a blazing fast solution.
(If you think that this should be an outrageous exaggeration, which it should probably be, but sadly isn't, check out some of the GH issues.
Some significant changes in the structure of directory which reduces the complexity of structure
This was a great idea, but the actual result is terrible. How the hell did M2 end up with more configuration and more XMLs? What's with the XML heavy UI components?
Is this the example of the simplified module structure – https://github.com/magento/magento2/tree/2.3-develop/app/code/Magento/Catalog?
Yeah sure, M1 is not great here, but M2 did not improve here at all, just check out the amount of the xmls in a single module – https://github.com/magento/magento2/tree/2.3-develop/app/code/Magento/Catalog/etc
New technologies and latest versions (example Php, jQuery etc)
Sure, and stuff like ZF1, KnockoutJS and Fotorama.
Allows developer to setup automated test easily
I agree here. M2 has a proper support for automated testing, while M1 has almost none.
Many features are now integrate to Magento 2
I'm not sure what exactly you wanted to say here, but the problem I had is that they simply migrated features from M1 to M2, didn't improve them at all, slapped new interface on top of it and call it new platform.
While there's no problem here, I feel like this was a huge opportunity to improve the system, but they dropped the ball.
Improvements to checkout and other stuff
I disagree, checkout is now not as nearly flexible as it was. Working with KnockoutJs and UI Components is the last thing you want to do.
I'm fine with it being quirky and all, but the flexibility and possibility to improve checkout per particular shop is nowhere near M1.
There is any index to look up to decide when is a good moment to migrate to Magento 2?
Most of the Magento agencies are using this to promote their services and offer migrations to M2 as a way to make extra profit. So you'll always see companies talking about performance and feature improvements which aren't there.
This is the only case where someone says something differently: https://amasty.com/blog/magento-1-vs-magento-2-performance-comparison-speed-test-results/ (I'm in no way affiliated with Amasty).
There are any hidden issue I have to know before?
Platform is not stable enough, major bugs are still present. Just do a quick browse through issue reports on GH.
Why Magento 1.x is still releasing new security updates if there is Magento 2?
There are lots of businesses that will never migrate to M2. They have no option here.
Lastly, I want to say that I'm sorry for all the hate in this answer, really wasn't my intention. :D
There is any index to look up to decide when is a good moment to
migrate to Magento 2?
It depends on individual store environment (Big stores with own ESB may use M2 as storefront, small ones will have to wait until their ERP Provider releases a plugin or connector)
There are any hidden issue I have to know before?
M2 code architecture is nothing like M1. MVC has been dropped in favour of MVVM
Someone ever try this migration? If yes do you see this big
improvement?
yes. FPC has been improved alot and general ttfb response is a way better
All my modules (third parts & hand-written) will be obsolete?
yes, due different design patterns.
Why Magento 1.x is still releasing new security updates if there is
Magento 2?
Magento inc. has promised ongoing support for M1. There are too many enterprise customers I guess.
I have tried the Magento 1 to Magento 2 migration a few times before. But for me, there is only one reason I can think that stands out, to do such a major overhaul on a website, and that is security,
You should not just upgrade to Magento 2, but specifically 2.3 as it has a lot more invested in security and less prone to malware attacks. It also has new features that did not exist in Magento 2.2.
If you are still on Magento 1, then in theory, it's only a matter of time before malware finds your site.
A good practice would be to have a fork of this repository https://github.com/magento/magento2 and bring the latest fixes into your code periodically. This would of course give you another reason to upgrade to the latest version since Magento 1 is no longer maintained.
You will have to reproduce all of your modules for Magento 2, there is absolutely no other way, And if you use the Data Migration tool, you should have an easy time bringing the data over. And the next point is going to be to create the theme for your site once more, there is no easy way to bring your theme over from M1 either.
Good luck my friend =D
As the title says, is it possible? Right now, we have Java 6 + sqljdbc4 + glassfish 2.1.1. We're planning on upgrading our Java 6 to Java 8 in order for Sqljdbc42.jar to work, because we are having JDBC Connectivity issue and the solution might be to upgrade to sqljdbc42. Please see Option 1 in this link:
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/11/30/intermittent-jdbc-connectivity-issue-the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption-error-sql-server-returned-an-incomplete-respons/
Of course some of you might say to upgrade Glassfish to a later version but in case is this is not an option, would errors occur? I found out that editing the asenv.bat will do the trick (http://alvinalexander.com/blog/post/java/fixing-glassfish-jdk-path-problem-solved) but I'm not sure about the deeper problems we might face.
Thank you so much for your answers.
You would have to be very brave (and have lots of free time) to try jdk-8 on glassfish-2. While you can still download glassfish-2, the Extended Support support ends this year (2017). This is not even Premium Support, it's Extended meaning you have already gone too far by this time. I know this because of a client I used to work for that used glassfish-2.
There were multiple bugs and complaints reported or the 3-rd and 4-th versions with jdk-8, not even speaking of 2-nd. Unfortunately you should upgrade to something way more recent (and have a constant plan to upgrade from there still). Obviously you can try and change the jdk version and see what happens - but I bet you would be visiting this site way more often than you would want to.
The real reason why you should seriously consider upgrading is that not a lot of people can answer deeper problems we might face, because not a lot of people use this version. Just my 0.02$.
I have been deep-divining in osgi from past few months and must say impressed by it. In recent days I saw one blog saying that impala is better than osgi. I heard about impala but never got a chance to deep-dive into it.
I just want to know that which one better Impala or OSGi? Is anyone is working on impala?
For developing large enterprise application one should go with osgi or impala and why?
Impala is an implementation of a framework from one person (company?). OSGi is a specification that is supported by all major IT vendors. It has been around for 10 years. There are 4 very popular open source implementations of OSGi available: Concierge, Knopflerfish, Felix and Equinox.
OSGi is used in thousands of embedded applications, it is the core of Eclipse, IBM and Oracle use it in strategic applications.
Though this of course does not say anything about technical superiority, you could imagine that the OSGi specifications have had a bit more real life weathering ...
You might find the following article useful for understanding when one might be more beneficial than the other:
http://osgi.dzone.com/articles/impala-alternative-module
Of note is the observation that
with Impala you don't get versioning and reloading of third party
libraries within the application
which is an important difference with OSGi
i think this is more of a debate... people who use Impala will say Impala, and those who use Spring OSGi will say OSGi; it's like Java vs C# or ASP.NET vs. PHP.
If you want to decide what is best for you, then just jump right into both of them, and see with which you are more confortable.
Before that read blogs about both maybe that will make you skip the whole diving into both step.
http://impalablog.blogspot.com/2007/11/impala-and-osgi.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
So, I've got an idea for a website. I can start off using any platform and frameworks I want, but there are almost too many options.
OS Platform:
Windows, *nix
Web Framework:
Rails, ASP.NET, ASP.NET MVC, Django, Zend, Cake, others
Hosting:
EC2, Dedicated Server, Shared Hosting, VPS, App Engine, Azure, others
Persistence:
S3, MySql, PostreSql, Sql Server, SimpleDB, CouchDB, others
How do you avoid decision paralysis and get started?
Firstly, your familiarity with a framework's language should dictate which framework you choose. Don't add the burden of learning another language on top of learning a framework.
Next, have a look at the remaining frameworks. Do they have good documentation? What about the community. (A good community can go a long way to making up any shortcomings of a given technology.) Does the framework solve the problems that you need solved?
Finally, just dive in and try something! Pick the one that makes the most sense to you and start writing code. Don't do too much hand-wringing over your decision. If it becomes obvious that you made the wrong choice, it should be obvious quite early. Learn from what you've accomplished so far and consider restarting with a different technology. (Just don't get several weeks down the road before you make this decision!)
I'm sure you don't like all of those technologies equally. Pick a framework that you like and get to work.
It depends on what your app is going to be doing. A handful of the technologies you listed are direct competitors (like Django vs. Rails), but some are completely different ways to do things (like MySQL vs. S3).
Questions to answer before you begin:
Will the app need to be horizontally partitioned in the near term? If so, using EC2, Google App Engine or Azure would be a good option.
Will your app fit into the constraints of Google App Engine? If so, it requires a lot less hassle on your part than running on bare metal (whether real or virtual).
What's your preferred web framework? If you want an MS framework, you'll need to run on a host that supports that.
What will your persistence and data access patterns look like? This will determine whether to use a database or something more exotic.
If you are running on EC2, the other AWS services are more appealing. Similarly, if you are using GAE, you have only one option for persistence. If you are using Rails, may as well start with MySQL.
In answer to your question of how to reduce the number of options, the answer is to realize that many of the options are related, so you don't have as many choices to make as it first appears.
Some advice that was once given to me is, pick what your friends (or colleagues) are using. Having people around you that you can share ideas and the learning experience with is invaluable.
If you want to learn something new: I'd just go with your gut and get started. If it sucks then switch to something more familiar.
If you don't have much time: Go with what you know and forget about the other options. Just start coding.
Optimize for happiness. Pick the one that you like the most. Or the one that intrigues you the most.
I've worked in Microsoft shops, in Ruby on Rails, and in homegrown shops having Apache, Jetty, even Mason.
All frameworks have their warts, their idiosyncracies that will keep you up until 3 AM, and their "tribal knowledge" vagaries that will be completely unexportable to other frameworks. (The last point is sometimes by design, the whole "platform entrenchment" business strategy)
Listen to what the supporters of the frameworks say about the problems with the other frameworks (Google: X framework vs Y framework). Pick the framework that has the loudest supporters. If they are equally loud, make the decision with a dice roll.
With me it's simple.
I only know MS stack and see no point in "checking out" all of those you mentioned.
No, actually I once tried to use JSF before excluding it from my list permanently.
Use what you are experienced in and where you can be more productive. The objective is to get your site up and running. Go for it.
One of the biggest factors in determining which platform/framework to use is your budget. You have to factor in the cost of licensing, software required to develop/maintain your website and other miscellaneous costs.
I suggest you begin with a scorecard of your own construction. Perhaps you can find different ones on the web, but if you do, modify them to meet YOUR needs. There should be a scorecard for each level in the stack (as you've described). Each scorecard should share some aspects to grade with other scorecards but each will also have their unique aspects.
Once constructed, weight each aspect graded according to your needs.
Once you've chosen the weights, pick the scales for grades.
At this point promise yourself you wont mess with the weights or the scale and then start collecting data on your options for each level in the stack.
You may also want to put a time limit on the collection period.
Make your decision based on the outcome of the scorecard.
The beauty of this approach is that the effort is made in constructing the scorecard, not in circular arguments of options. The effort in making the scorecard is vendor agnostic and focuses on the desired result, not the options. Thus you can avoid paralysis.
One more thing, my best scorecards have included sections addressing the availability of resources and other human related things. Don't make the mistake of just looking at the technology.
good luck.
Go for personal preferences.
One decision at a time:
Firts I would begin with type of language:
Script: PHP, Python,
Serious: Java, .Net
The language will restrict your OS, plattform and will give you hints for the dataabse decission. The database load is also important. And, Do you want logic in the DDBB? how much data?
Last advice. Try combinations well tested. LAMP, WAMP, Windows with SQL Server and .NET.
Evaluate each platform and technology for quality of tools for your needs. For example, if you are cost sensitive, you would value free operating systems and tools higher than costly ones. If you need performance, you would value tools which provide high performance higher than ones that don't.
It entirely depends on your situation. I spent several months evaluating stuff for a new commercial web site last year, and it was very easy to feel paralized. In the end it was talking to several people who'd done similar things, and of course reading a lot of stuff online and from Amazon. I chose Java, since our team had a lot of experience in it, and it has good performance and extensive supporting technologies. Oracle is our database but we used a persistence manager to make it easy to change later on. We used a half-dozen very good libraries to eliminate much of the boring and repetitive coding (Restlet, iBatis, Freemarker, XStream, jQuery, SLF4J). We used Glassfish as our web server.
Yours sounds like a small project with only you to work on it. In that case, pick a complete framework instead of a smorgasbord like we did. Pick something fun to work with, and something with good "return on resume". Look very hard at Ruby on Rails, Django (kind of a Python on Rails), and Groovy on Grails (a Rails-wannabe for the Java world). In your shoes I'd pick Ruby on Rails because there's a large and growing community and a good number of books and tutorials. Plus, Ruby looks like a worthwhile language to learn. For your database, just pick one. These frameworks make it easy to change your mind later. Pick MySQL unless you have another you like better.
And as other posters said, just do it! ;-)
Like others said, pick something you and your employees are familiar with. I highly doubt you are close to being industry ready with all those techs.
OS Platform: Windows, *nix
Shouldn't matter except for Windows licensing costs, and that is probably the least of your expenses.
Web Framework: Rails, ASP.NET, ASP.NET MVC, Django, Zend, Cake, others
Dependent on your favorite language
Hosting: EC2, Dedicated Server, Shared Hosting, VPS, App Engine, Azure, others
You should design your product to be movable, so you can scale among these. If you know for sure you are going big, then just start off with EC2. App Engine is extremely limiting, ex. they don't let you form outbound connections.
Persistence: S3, MySql, PostreSql, Sql Server, SimpleDB, CouchDB, others
You need to do the research yourself whether or not your product requires an RDBMS or a simple key/value store, and what features each of these have.
Just go for it! Your platform choice really is not all that important as long as you make a reasonable choice (Ruby + Rails, Python + Django, PHP + Cake/CodeIgniter). Any of these can be used to build successful sites. If your site really takes off, you'll be able to scale it fine.