IDE: 5 most favorite NetBeans features

Development with pleasure....
NetBeans has many interesting features that make development very easy, with few steps, and makes for a very productive environment, in terms of getting your product to market very quickly.

It is very hard to limit my talking to only five features, while this IDE has tons of interesting features. But here I am going to mention my most favorite 5 features I am daily using in my development process on many platforms:

1. It is the reference development implementation IDE:
   

   I am a JCP (Java Community Process), EC (Executive Committee), a JSRs (Java Specifications Request) adopter and FishCAT (Glassfish Community Acceptance Testing) contributor especially in Java, SE & EE world. While I am in early phases of testing the specifications, I need an IDE which support those technologies and made it easy to test and develop them, to report bugs, enhancements and confirms that JSRs Specs are valid against RIs, and with other JSRs on latest RI Application server like Glassfish.
   

   NetBeans offered all of this for us to streamline the process, with almost a nightly and weekly builds alongside JSRs RIs builds, which we use to test previously mentioned RIs betas.

   The most interesting part of the story here is when we released Java EE 7 on last Mid of June 2013; there was already NetBeans 7.4 was generally available released to fully support development of Java EE 7 technologies. And this happens also for JDK 8 when it released 18-March 2014, there was NetBeans 8.0 fully support Java SE 8.0.

2. Android Mobile development made easy:
   

   NetBeans shipped with a very great support for mobile development either it was pure Android development in term of this is a Java Based IDE or Hybrid development in term of frontend technology support (HTML5, CSS3 and JavaScript).

   With a very productive plugin NBAndroid you can develop a pure Android project compatible with original ADT SDK (Android Development Toolkit) project structure, test, emulate and deploy on emulators as well as native devices at the same time. You should give it a try if you interested in mobile development.

   Create a new Project:
   
   
   
   
   
   Identify Properties:
   
   
   
   
   
   Created project:
   
   
   
   
   
   Runs On Android Emulator:
   
   
   
   
   
3. Hybrid Mobile development support:
   

   Hybrid mobile development is never made easy as now in NetBeans nowadays, NetBeans introduced a hybrid mobile development based on Cordova open source mobile framework. Which is one of the most popular frameworks to develop hybrid mobile applications.

   While NetBeans gives a great and solid support for frontend engineering technologies like JavaScript, HTML5, CSS3, Frameworks like AngularJS, NodeJS, and jQuery core, mobile, and UI … etc.

   Which made it easy to develop a Hybrid based mobile applications for both Android and iOS in one shoot with few clicks. Without context-switching to other IDEs to accomplish the task.

   It has complete support for Apple iOS development toolkit and Android ADT SDK, therefore you can test your application locally for mobile web and on emulators/devices of both mobile OSs, then export final product either it was .apk binary for android or .ipa for iOS, for final deployment on Apple store or Google play store.

   Creating the project:
   
   
   
   
   
   Choosing template:
   
   
   
   
   
   Identifying project properties:
   
   
   
   
   
   Choosing deployment method:
   
   
   
   
   
   Deployed on iOS simulator:
   
   
   
   
   
4. JavaScript libraries in one place:
   

   If you are a frontend engineer, then you got the right choice, yes this IDE is for you, I know you need to develop a modern web application, but wait this needs many JavaScript modules and libraries to do it.

   One among the very panic tasks in web development nowadays, is to search for JavaScript tools and setup your project for them, then download each JavaScript libs from different sites with there resources and support libs, in addition you have also to manage their updates to fix problems or get a new feature.

   NetBeans comes with a build in tool that allows you to get your JavaScript libraries in one shoot from the IDE directly and mange their updates from the same place.

   You will find almost all JavaScript libs you need, and you can filter your choice from the tool to pic up the right libs you need for your project, and where to put them in your project.

   As mentioned in first picture the libs were updated on Apr 26, 2014, just click and will updates all libs to today releases.

   It saves me a bunch of site visiting and worrying about updating them, and even adding new ones in future of the project.

   The JavaScript tool:
   
   
   
   
   
   Pickup and filter your choices:
   
   
   
   
   
5. SOAP based client/Web Services in one click:
   

   I am working in government environment, which requires much integration between systems either directly or through a G2G (Government-to-Government) hub, each one needs a specific integration requirements.

   If it is directly, you have to define you web service annotations on interface based on your backend EJB session bean interface or separate endpoint interface to decouple your Endpoint from your façade, then generate WSDL to be consumed by others.

   Other scenarios is to go to a Top-Down approach, in developing WSDL first to be certified on G2G hub based on their standards, then generate service endpoint interface from them.

   Lately I have been asked to develop a Pension G2G WSDL definition and at the same time generate endpoint service interface to begun the testing in one week.

   I have accomplished this task in 3 days using NetBeans, it has a tremendous support for XML, XSD development, and after finishing the WSDL definition, I need to confirm a correct endpoint service creation, Before publishing service WSDLs to G2G authors.

   Okay from NetBeans I have created a Web Service from WSDL, passed the WSDL and click finish, that’s all.

   The surprise was it generates the service endpoint correctly as WSDL def. and at the same time created Service ports and client to test service in one shoot.

   All I have to do is to implements my service endpoint operations and huryaaaa finished my task.

   Adding WSDL and Identifies project attributes:
   
   
   
   
   
   Generated Service endpoint:
   
   
   
   
   

Thanks for NetBeans team for such support and made it a development with pleasure.

Architecture: Modeling & Designing Software Projects Architecture

When I model and design the architecture of software project, first thing I consider is what is the software project type?

My experience in this field of projects architecture has taught me that most applications fails into seven software types, each type has its own technology's, communication patterns, architectural patterns and design steps.

The software categories are:

1. Object oriented Software:

The object-oriented design uses the concepts of information hiding, classes, and inheritance. This results in the design of a sequential object-oriented software architecture, which would be implemented as a sequential program with one thread of control.

2. Client / Server Software.

In these systems, a client is a requester of services and a server is a provider of services. Typical servers are file servers, database servers, and line printer servers. Client/server architectures are based on client/service architectural patterns, the simplest of which consists of one service and multiple clients. This pattern has several variations, which will be described next. In addition, certain decisions need to be considered about the design of client/server architectures, such as whether the server should be designed as a sequential or concurrent subsystem, what architectural structure patterns to use for the design of the client/server architecture, and what architectural communication patterns to use for interaction between the clients and the services.

Also differentiates between a server and a service. A server is a hardware/ software system that provides one or more services for multiple clients. A service in a client/server system is an application software component that fulfills the needs of multiple clients. Because services execute on servers, there is sometimes confusion between the two terms, and the two terms are sometimes used interchangeably. Sometimes, a server will support just one service or perhaps more than one; on the other hand, a large service might span more than one server node. In client/server systems, the service executes on a fixed server node(s) and the client has a fixed connection to the server.

3. Service-Oriented Architecture.

SOA is a distributed software architecture that consists of multiple autonomous services. The services are distributed such that they can execute on different nodes with different service providers. With a SOA, the goal is to develop software applications that are composed of distributed services, such that individual services can execute on different platforms and be implemented in different languages. Standard protocols are provided to allow services to communicate with each other and to exchange information. In order to allow applications to discover and communicate with services, each service has a service description; the service description defines the name of the service, the location of the service, and its data exchange requirements.

A service provider supports services used by multiple clients. Usually, a client will sign up for a service provided by a service provider, such as an Internet, email, or Voice over Internet Protocol (VoIP) service. Unlike client/server architectures, in which a client communicates with a specific service provided on a fixed server configuration, this chapter describes SOAs, which build on the concept of loosely coupled services that can be discovered and linked to by clients (also referred to as service consumers or service requesters) with the assistance of service brokers. This document describes how to design SOAs, how to design services, and how to reuse services.

4. Distributed Component-Based Software.

In the design of software architectures for a distributed component-based software design; the component-based software architecture for the distributed application is developed. The software application is structured into components, and the interfaces between the components are defined. To assist with this process, guidelines are provided for determining the components. Components are designed to be configurable so that each component instance can be deployed to a different node in a geographically distributed environment.

Components are initially designed using the subsystem structuring criteria. Additional component configuration criteria are used to ensure that components are indeed configurable – in other words, that they can be effectively deployed to distributed physical nodes in a distributed environment.

5. Concurrent Real-Time Software.

The real-time software is a concurrent architecture usually, having to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control.

Real-time software architectures are concurrent architectures that usually have to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control. Thus, the design of finite state machines, state-dependent interaction modeling, and the control patterns, are very important in the design of real-time software architectures.

6. Software Product Line.

It is architectures for families of products that need to capture both the commonality and variability in the family.

A software product line (SPL) consists of a family of software systems that have some common functionality and some variable. Software product line engineering involves developing the requirements, architecture, and component implementations for a family of systems, from which products (family members) are derived and configured.

The problems of developing individual software systems are scaled upwards when developing SPLs because of the increased complexity due to variability management.

As with single systems, a better understanding of a SPL can be obtained by considering the multiple views, such as requirements models, static models, and dynamic models of the product line. A graphical modeling language such as UML helps in developing, understanding, and communicating the different views. A key view in the multiple views of a SPL is the feature modeling view. The feature model is crucial for managing variability and product derivation because it describes the product line requirements in terms of commonality and variability, and defines the product line dependencies. Furthermore, it is desirable to have a development approach that promotes software evolution, such that original development and subsequent maintenance are both treated using feature-driven evolution.

7. Framework Software.

A software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API). It is a universal, reusable software platform used to develop applications, products and solutions.

Software Frameworks include support programs, compilers, code libraries, an application programming interface (API) and tool sets that bring together all the different components to enable development of a project or solution.

Frameworks contain key distinguishing features that separate them from normal libraries:

7.1. Inversion of control - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.

7.2. Default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.

7.3. Extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.

7.4. Non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.

-----------------------------------------------------------------------
Last thing is very important should be considered when architecting any project. It is Non-Functional requirements and should be taken into consideration when designing such software types from the modeling and design stage not when implementing the project.

In my architecture document I called it Software quality attributes.

Software quality attributes:

Refer to the nonfunctional requirements of software, which can have a profound effect on the quality of a software product. Many of these attributes can be addressed and evaluated at the time the software architecture is developed. Software quality attributes include maintainability, modifiability, testability, traceability, scalability, reusability, performance, availability, and security.

Some software quality attributes are also system quality attributes because they need both the hardware and software to achieve high quality. Examples of these quality attributes are performance, availability, and security. Other software quality attributes are purely software in nature because they rely entirely on the quality of the software. Examples of these quality attributes are maintainability, modifiability, testability, and traceability.

Architecture: Can You Relate?

Your success as a software architect depends on your relationships with stakeholders.

Being a software architect is all about relationships. No, forgetting your anniversary or not getting along with your mother-in-law won’t necessarily have any impact on your success as a software architect. But unless an architect’s relationships with project stakeholders are based on clear communication and a thorough understanding of expectations, the project is likely to end in a scene befitting a reality television show, with at least the possibility of flying furniture and crushed dreams.

So if you want to succeed as a software architect, establishing a solid relationship with stakeholders and a crystal-clear understanding of their expectations must be job #1 on any project.

The first step in that process is knowing whom you’re dealing with. Identifying stakeholders is essential. “You need to know who has the power to call an engagement a success or failure,” says Pat Shepherd, enterprise architect at Oracle.

But there’s more to building relationships than memorizing names and roles—you need to get inside stakeholders’ heads. “Make sure you know the stakeholders and what’s driving them,” says Oracle ACE Director Ronald van Luttikhuizen, a solution architect and senior consultant at Approach Alliance, a Netherlands-based information and communications technology consultancy focusing on SOA and business intelligence.

Randy Stafford, a software architect with the Oracle Coherence development group, agrees. “The first thing I do is make sure I understand the motivation for the project, because it usually translates directly to measurable success criteria,” Stafford says.

Once you know what your stakeholders want, you need to make sure they understand what you bring to the table. “Stakeholders should know you and understand your added value and what you want to achieve with them in the project,” says van Luttikhuizen. Stakeholders need to smell what you’re cooking and like it, because the project has little chance of succeeding without their complete support.

“This may sound a bit trivial,” adds van Luttikhuizen, “but I’ve seen too many ivory-tower architects who just throw something out there. Without stakeholder support my architectural activities will not be followed and will just end up gathering dust.”

In order to earn that support, Brian Jimerson, a technical architect at Avantia in Cleveland, Ohio, sets up a project kickoff meeting with his internal customers. “I want to ensure that project goals are understood, establish communication channels, identify stakeholders and roles, and discuss the high-level project schedule,” Jimerson says. He also holds similar kickoff meetings with development teams to discuss project goals, milestones, and team structure.

Once you and your stakeholders are on the same page, it is time to impress everyone by waving your architecture wand. “In between the first steps and the project completion, a combination of creativity and engineering happens to identify and implement architectures that meet the goals,” says Stafford.

But there has to be some substance behind the magic. As the project progresses, it’s important to maintain your relationship with stakeholders by demonstrating your progress. “I try to deliver something useful as early as possible in the project,” says van Luttikhuizen.

“Depending on the type of architecture assignment—whether my role is software architect, solution architect, or enterprise architect—this can be a quick advice document, a working piece of software, or a guideline to help stakeholders.” These project milestones are important not just as progress indicators but also as proof of the value of architecture.

In the end, software architects are really only as good as their relationships with stakeholders. “Let’s face it—the critical thing for an architect’s career is to build a good reputation,” says Shepherd. Good reputations don’t spring from dysfunctional relationships with stakeholders.

If you want to earn your stripes as a software architect, you can’t relate to stakeholders by flinging furniture at them across the conference room. You need to understand what they want. They need to understand what you can deliver. Bring those two elements together through clear communication and everybody wins.

Design pattern: What is software design patterns?

In software engineering,

A design pattern is a general reusable solution to a commonly occurring problem in software design.

A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.

Design patterns reside in the domain of modules and interconnections. At a higher level there are architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.

There are many types of design patterns, like Algorithm strategy patterns addressing concerns related to high-level strategies describing how to exploit application characteristic on a computing platform. Computational design patterns addressing concerns related to key computation identification. Execution patterns that address concerns related to supporting application execution, including strategies in executing streams of tasks and building blocks to support task synchronization. Implementation strategy patterns addressing concerns related to implementing source code to support program organization, and the common data structures specific to parallel programming. Structural design patterns addressing concerns related to high-level structures of applications being developed.

Also:

A design pattern describes a recurring design problem to be solved, a solution to the problem, and the context in which that solution works (Buschmann et al. 1996; Gamma et al. 1995). The description specifies objects and classes that are customized to solve a general design problem in a particular context. A design pattern is a larger-grained form of reuse than a class because it involves more than one class and the interconnection among objects from different classes. A design pattern is sometimes referred to as microarchitecture.

After the original success of the design pattern concept, other kinds of patterns were developed. The main kinds of reusable patterns are as follows:

·         Design patterns. In a widely cited book (Gamma et al. 1995), design patterns were described by four software designers – Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides – who were named in some quarters as the “gang of four.” A design pattern is a small group of collaborating objects.

·         Architectural patterns. This work was described by Buschmann et al. (1996) at Siemens. Architectural patterns are larger-grained than design patterns, addressing the structure of major subsystems of a system.

·         Analysis patterns. Analysis patterns were described by Fowler (2002), who found similarities during analysis of different application domains. He described recurring patterns found in object-oriented analysis and described them with static models, expressed in class diagrams.

·         Product line–specific patterns. These are patterns used in specific application areas, such as factory automation (Gomaa 2005) or electronic commerce. By concentrating on a specific application domain, design patterns can provide more tailored domain-specific solutions.

·         Idioms. Idioms are low-level patterns that are specific to a given programming language and describe implementation solutions to a problem that use the features of the language – for example, Java or C++. These patterns are closest to code, but they can be used only by applications that are coded in the same programming language.

SE: Software Engineering

Software engineering (SE)

is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build. It is a "systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software.

The term software engineering first appeared in the 1968 NATO Software Engineering Conference, and was meant to provoke thought regarding the perceived "software crisis" at the time.

The IEEE Computer Society's Software Engineering Body of Knowledge defines "software engineering" as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

It is the application of Engineering to software because it integrates significant mathematics, computer science and practices whose origins are in Engineering.

Software development (SD)

A much used and more generic term, does not necessarily subsume the engineering paradigm. Although it is questionable what impact it has had on actual software development over the last more than 40 years, the field's future looks bright according to Money Magazine and Salary.com, which rated "software engineer" as the best job in the United States in 2006.