Plug-in to Vegas The program focuses on key topics such as high availability, virtualization, security, business intelligence, Exadata, Cloud Computing and internals. Recently added, we switched around the schedule to include the Thursday Deep Dive, Avoiding Downtime through the Maximum … Continue reading →
PlanetMySQL Voting:
Vote UP /
Vote DOWN
Archive for the ‘developer’ Category
Collaborate 2012 Registration is Now Open!
Февраль 2nd, 2012
 |
|||||||
|
|
||||||
 |
|||||||
PlanetMySQL Voting: Vote UP / Vote DOWN
OTN Developer Day: MySQL is Coming to Washington, DC
Август 9th, 2011We organized our first OTN Developer Day: MySQL earlier this year in Santa Clara, CA, and the result far exceeded our expectation. Before we kicked off the seminar at 9am, the attendees had already taken every single seat in the beautiful auditorium in Oracle's Santa Clara campus, and there was still a line in front of the registration desk. We recruited MySQL experts from several teams to present, and had great questions and discussions along the way and at the end. I personally received many positive comments saying that the seminar was very useful and informative.
This time, we're bringing the Developer Day to the East Coast! On August 24, we'll host a full-day event in Washington, DC, where you can learn all the essential skills to successfully design, develop, and manage your MySQL and MySQL Cluster databases. You’ll also learn the guidelines and best practices in performance tuning and scalability.
The event located near the Washington Convention Center, so if you're attending GOSCON/Innovation Forum on August 23, stay one more day to learn about MySQL!
Time:
Wednesday, August 24, 2011
8:00 a.m. – 3:30 p.m.
Location:
Renaissance Washington, DC
Downtown Hotel
999 Ninth Street NW
Washington, DC 20001
Don’t miss this exclusive opportunity to learn tips and tricks from the MySQL experts at Oracle, and network with your peers. Whether you’re a DBA or a developer, register now and find out how you can make the best of MySQL in your IT infrastructure or in your commercial products and applications.
PlanetMySQL Voting: Vote UP / Vote DOWN
Adopting RAD in the Enterprise: The 14 Biggest Misconceptions
Ноябрь 29th, 2010Rapid Application Development (RAD) is a way of developing computer software applications with less effort than the traditional means.
RAD tools focus on providing code generation and automated testing capabilities with the use of convention over configuration to provide a streamlined workflow to create applications.
Even with the most advanced and easiest to use RAD tools, there are times which the traditional enterprise and the business software development vendors which are having their own implementations and in-house built frameworks are continuously refusing to adopt them.
Most of the misconceptions on the RAD are based on FUD (Fear, Uncertainty and Doubt) which has been created around the internal complexity of the RAD tools.
Here we take a look at the biggest common misconceptions on RAD tool adoption in the enterprise.
1. RAD tools are magical
This is a common myth among the developers who insist on writing their own code from scratch.
Due to the elegance and the accuracy of properly generated applications, they will assume that the changing of generated code would cause the application to lose its beauty.
They are reluctant to see patterns in commonly developed applications which could be easily generated by the use of RAD tools.
2. You can’t make changes to the generated code
Most of the code generated by the RAD tools are editable, but takes a developer who has the understanding on the related technologies.
When people do not have the exposure to the technologies beneath the RAD generated code, they will start to spread fear and doubt on the customizability of the generated application.
3. RAD tools are for simple applications
Yes, simple applications can be generated by RAD tools, but it doesn’t limit you from creating a large application with the use of the tool.
As long as your application is properly designed, RAD tools will always have a solution.
Agree or not, most of the current applications with support to the cloud are the ones built with RAD tools.
4. You can’t make mistakes while generating the code
Most RAD tools have the capability of correcting mistakes done while generating the code. In most cases, even if you have made a mistake that the tool cannot reverse, there will be a manual way you can correct it.
5. You can’t make complex user interfaces with RAD tools
First, ask yourself whether you really need a complex user interface. The users are really comfortable using a simple, elegant and consistent user interface, rather than a complex and bloated user interface.
Even if you want a complex user interface, you can always integrate your generated code to your own user interface.
6. RAD is for startups, not for big businesses
If you are a big business, you will benefit more from RAD than a startup, because your development and testing time would be significantly reduced due to the reuse of patterns.
Actually, big businesses use RAD, but will not tell you.
7. You can’t integrate RAD applications with other systems
This again is due to the lack of knowledge about the particular application development framework. Almost all of the RAD tools provide means of exposing services to integrate your generated application to other applications.
8. You can’t work in a team setting or use a Version Control System (VCS)
You can always check-in your generated code to the VCS, and work in collaboration. In most of the cases, you just have to make sure only one developer is responsible for the use of tool for a particular module of the application.
9. RAD tools lock you in for a particular technology
Before asking this, ask yourself how much you is locked into the technology which you are currently using.
Most tools provide a humble way to remove the RAD tool dependencies and continue the project as a handwritten project.
10. People who can code should always code, instead of using tools
People who can cook, should always cook? No. Especially when they are given a machine which can create any delicious meal, once the guidelines are defined by the cook? No, not at all.
People, who can code, are the best people to properly use RAD tools, as they understand the tool better, and are able to extend and make the maximum use of the power of the tool.
Additionally, they can write add-ons, application specific and platform specific components to better match the business needs while increasing productivity to the organization as a whole.
11. RAD tools reduces the job security of the developers
This is largely false, as the tool would only increase productivity. Developers would have more time creating ‘applications’ instead of creating ‘application code’. As the tests and the related scripts are automatically generated they would have more time for manual testing of the application and to cater more requirements instead of battling the complexities arising from day to day changes to the application.
12. You can’t maintain generated applications with RAD tools
Before asking this question, look at your own code and see how much legacy code and technologies are still present. One thing you would understand is that application code never grows old or dies. As long as it works, it will be alive.
Using RAD tools, you will always have the particular version of the tool to make changes to the existing code based on the available capabilities. Even if a new version comes along, it will be mostly backwards compatible and would even have capabilities to support the conversion of the existing generated code to the new code to make it better. This is largely possible due to the proper use of patterns in the generated application.
13. RAD is complete
The perfect RAD tool is not yet complete, but the current tools have been evolved over the years and are usually more than enough for almost all businesses. Most tools would provide you ways to enhance the tool in order to better cater for your individual needs.
14. RAD will take your house, your spouse, everything you have and leave you with nothing.
No. Really?
These are just the biggest misconceptions; the rest will be covered in a next post on this blog.
Additional Resources:
Frameworks and Tools
Read more posts on this blog :
- Nokia and Symbian : Business and Software : Lessons To Be Learnt
- What Apple taught other businesses tonight.
- Flash and Runtimes on Mobile Devices, Who is right? Steve Jobs or Adobe?
- MySQL is gone. Here comes MariaDB and Drizzle.
- Is Open Source software a classic example of fail for Design by Committee?
- Why a ‘Single Line’ was added to the Solaris Terms of Use by Oracle?
- Oracle starts to monetize Free Software, is it wrong?
PlanetMySQL Voting: Vote UP / Vote DOWN
New Open Query training days in Australia
Октябрь 2nd, 2009The favourite Open Query course modules as well as reworked and brand new ones, with November/December 2009 dates for Brisbane, Sydney, Canberra and Melbourne listed below. You can register for days/modules individually, to suit your time, budget and current needs. Your trainers are Sean, Ray and Arjen (see OQ people).
For the Canberra and Melbourne days which are DBA/HA, registrations for all of the modules in a series before 15 October will receive a copy of the “High Performance MySQL” book (normal bookstore price is AUD 105).
- Thu 5 Nov: MySQL High Availability – Strategy and Tools
- Fri 6 Nov: MySQL Cluster Workshop
- Mon 9 Nov: MySQL Optimisation by Design
- Tue 10 Nov: MySQL Locking, Transactions & Storage Engine Optimisation
- Thu 19 Nov: MySQL Query Performance Optimisation and Tuning
- Fri 20 Nov: MySQL Server Performance Optimisation and Tuning
- Wed 9 Dec: MySQL Installation, Security and User Management
- Thu 10 Dec – Fri 11 Dec MySQL Backup and Recovery + Replication Workshop
PlanetMySQL Voting: Vote UP / Vote DOWN
And the best open source license is …
Сентябрь 1st, 2009This is my assessment as a judge of the recently-held open source license debate held by the FOSS Learning Centre. We’ll have to begin with some qualifications and definitions, starting with the fact that there is no ‘best’ open source software license. Still, a star-studded open source software panel provided a lively, informative debate on the merits of some top open source licenses. For that, I congratulate and thank the panelists, Mike Milinkovich from the Eclipse Foundation arguing for the Eclipse Public License, Matt Asay of Alfresco arguing in favor of the GPL and David Maxwell from Coverity arguing for BSD. All three put forth some of the most important attributes and shortcomings of the three open source licenses, as well as other, related open source licenses. However, using a complex, proprietary formula awarding points for goodness and minuses for badness, I was able to deem a winner: Mike Milinkovich and the EPL. Perhaps fitting that the license that can best be described as the middle of the spectrum should be the winner. Here’s why:
Matt Asay kicked off the discussion, which became more of a debate as it developed, with a consistent message about GPL’s dominance among open source software projects, which is 70% or more based on most accounts (and considering GPLv2 and GPLv3). He also referred to monetization and the fact that GPL serves as the basis for successful support and services models, such as Red Hat. However, Matt did not initially mention the strategic and defensive benefits of GPL, which is often chosen because it mitigates the threat of a fork that someone can make proprietary. I was also hoping for him to address how GPL can deliver benefits of open source without having to share as in the spirit of the license, based on whether and how the software is distributed. Nevertheless, Matt made his most compelling arguments around the fact that GPL is the primary open source model and the license that developers understand and trust most. He furthered his argument later by agreeing EPL may be better for lawyers, but GPL is better for developers. Matt reinforced these ideas with his reference to large companies using GPL software, such as Google or TiVO, that gets it to vast numbers of users.
Mike Milinkovich spoke second with some background on EPL, its origin as a ‘legal document’ and how it links open source software to commercial products. He also hit on the fact that EPL covers patent rights, which is certainly important to vendors and developers. He later referred to the meaninglessness of Matt’s 70% GPL figure, based on the idea that software on repository is something different than software in use (where other licenses do have greater representation). However, our research indicates that the most popular open source licenses among hosted code are consistent with the most popular open source licenses among code in use, with GPL, BSD and EPL all in the top. Mike also referred to commercialization and money, which is certainly important to commercial open source, but did not give equal mention to community until later. Still, Mike earned back a point when he referred to monetization of open source software among traditional vendors and organizations beyond VC-funded, open source startups, where we are seeing significant growth for open source software. While I would have liked to have heard an argument in favor of EPL based on compatibility, Mike also made a good case for EPL in government — another consistent theme of the discussion — where code would belong to the public with commercial opportunity on top.
David Maxwell signaled a more rebuttal-type response and gave it in his arguments for the BSD license, which he introduced as the oldest license given its roots to Unix and the ’80s. David scored a point for simplicity and straightforwardness when he read the actual license, something his peers would’ve had a hard time doing. David did somewhat jump the gun, though, on rebutting with his counterpoints about GPL’s strict copyleft requirements, which he called ‘enforcement-based.’ Still, David recovered with an argument for BSD based on its emulation, which he credited for other popoular licenses such as the Apache Public License and Artistic License.
The debate portion was followed by some good discussion of business models, open core and proliferation with questions from the live and Web audiences. So why does my vote for the winner go to Mike and the EPL? While it was certainly close on my card and all three made compelling arguments, Mike and his portrayal of the EPL were the most realistic and pragmatic to today’s open source software in the enterprise. Communities, copyleft and the sharing that allows developers and projects to sustain effective, productive open source efforts must be balanced with commercial interests, endeavors and aspiration. Neither open source communities nor open source commercialization would be nearly as significant without one another, and Mike’s arguments and statements seemed most closely attuned to that.
Thanks again to the panelists, participants and FOSS Learning Centre for putting on the event. Please get involved in the discussion and watch the debate, comment here or elsewhere.
PlanetMySQL Voting: Vote UP / Vote DOWN