Skip to main content

Home/ SoftwareEngineering/ Group items tagged requirements

Rss Feed Group items tagged

kuni katsuya

Enterprise Architect - Product Demonstrations - 0 views

  • Part 2 Subversion Setting up a Subversion repository for use with Enterprise Architect models.
  • Part 4 Configure & Connect Configuring Enterprise Architect and connecting to your Version Control system.
  • Part 5 Controlled Packages Working with version controlled UML packages in Enterprise Architect.
  • ...19 more annotations...
  • Eclipse A tour of MDG Integration for Eclipse.
  • Baseline Diagram Comparison Conduct a visual diagram comparison between your current diagram and a previous baseline .
  • Personal Information Window See how the Personal Information Window in Enterprise Architect can help you organize your daily tasks and workflow.
  • Working Sets As you perform work on your model, you open various windows, diagrams and views. Working Sets allow you to return to these same views in a later work session.
  • Business Rules A car rental system is used to illustrate how to generate executable business rules using Enterprise Architect.
  • Menu Customization Quickly and easily suppress individual menu items or entire categories of commands to create custom menu layouts.
  • Floating and Dockable Windows Save the position and layout of Floating and Dockable Windows using a Working Set in the Personal Information Window.
  • Build and Debug a Java Application Set up Enterprise Architect to build and debug a Java Application, using a VEA sample project.
  • Sequence Diagrams Learn how to create a simple Sequence diagram. The video also illustrates how to bring your Sequence diagram to life using model simulation.
  • HTML Report Generation This brief introduction illustrates how to automatically generate a HTML Report using Enterprise Architect.
  • Basic Use Case Demonstration A guide to constructing a Use Case model in under 30 seconds, including use cases, notes and issues.
  • Traceability within Enterprise Architect This video examines Traceability and discusses how to use Enterprise Architect to conduct an Impact Analysis.
  • Requirements Reporting A brief overview of requirements reporting in Enterprise Architect. Topics include document generation in web and RTF formats, report customization and virtual documents, including Model and Master documents.
  • Requirements Traceability An examination of requirements traceability in Enterprise Architect. Topics include traceability views, tracing to external artifacts, conducting an impact analysis, viewing the Relationship Matrix and using Enterprise Architect's Auditing capabilities.
  • Requirements Modeling A brief overview of requirements modeling in Enterprise Architect. Topics include requirements capture and definition, custom properties, tabular editing, auto-naming and screen prototypes.
  • Installing EA An introductory walk through and discussion of Enterprise Architect in the Software Development Lifecycle.
  • Enterprise Architect 7.5 Overview An overview of Enterprise Architect features released with version 7.5.
  • Introduction to Enterprise Architect An introductory walk through and discussion of Enterprise Architect in the Software Development Lifecycle.
  • Brief Overview The 10 minute guide to Enterprise Architect, from Requirements Management and Business Process Modeling to MDA and Code Engineering.
kuni katsuya

Appendix C. Spring Security Dependencies - 0 views

  • Spring Security Dependencies
  • This appendix provides a reference of the modules in Spring Security and the additional dependencies that they require in order to function in a running application
  • C.1 spring-security-coreThe core module must be included in any project using Spring Security.
  • ...8 more annotations...
  • DependencyVersionDescriptionaopalliance1.0Required for method security implementation.
  • spring-aop Method security is based on Spring AOP
  • spring-beans Required for Spring configuration
  • spring-expression Required for expression-based method security (optional)
  • spring-jdbc Required if using a database to store user data (optional).
  • spring-tx Required if using a database to store user data (optional).
  • C.6 spring-security-aclThe ACL module.
  • spring-jdbc Required if you are using the default JDBC-based AclService (optional if you implement your own).spring-tx Required if you are using the default JDBC-based AclService (optional if you implement your own).
kuni katsuya

TH01-EP03-US004 - Property Mgmt, Edit Location & Directions, Content Mgmt - Projects - ... - 0 views

  • Property Mgmt
  • Property Mgmt
  • Property Mgmt
  • ...18 more annotations...
  • Property Mgmt
  • Property Mgmt
  • Property Mgmt
  • As a user
    • kuni katsuya
       
      with what granted roles? from which organization?
  • ability to see
    • kuni katsuya
       
      permissions required: retrieve these resource types
  • Location Type
  • Description
  • Airports
  • belonging to other organizations
    • kuni katsuya
       
      content (license) owned by organization different than user's
  • clone this information
    • kuni katsuya
       
      clone = retrieve, then create ie. required permissions: {retrieve,create:}
  • have the rights
    • kuni katsuya
       
      generally speaking, there can be a few independent but overlapping mechanism that will control who is allowed to do what with content: 1. any subject's access to the content itself can be controlled via authorization rules (ie. required vs granted permissions) enforced via system-wide resource-based access control 2. content licensors (~content owners) can restrict the usage of their content by: * whom - ie. content licensee (legally/commercially represented by an organization) * how - eg. reuse as unmodified, create derivatives, composite, redistribute, etc * where - ie. distribution channels their content can be used (eg. only on hotel's vbrochure site, but not in any ids/gds channels) * when - temporal restrictions may limit scope of content license grant by: start, end, duration, season, etc 3. content licensees can further filter or funnel content available to them (resulting from a combination of license granted to them and access control) based on their own criteria (eg. generate a templated hotel presentation only if: at least 1 textual description, 5 photos and 1 video for a hotel is available with a license to combine them (composite content)
  • see how other organizations describe the property
    • kuni katsuya
       
      permission required: retrieve hotel descriptive content(?) owned by independent organization
  • Property Mgmt
  • which textual information
  • displayed
    • kuni katsuya
       
      displayed where? on specific channels?
  • ECM will ask user to confirm that the user has rights to use that content
    • kuni katsuya
       
      if ecm/vfml is to manage content licensing as a third party between organizations (content licensors & licensees) shouldn't ecm *know* if the user('s organization) has rights to use the content in question? is this question posed to the user (with required explicit acknowledgement) purely to absolve vfml from liability issues that may result from licensing disagreements?
  • property’s
    • kuni katsuya
       
      this being the user's (organization's) 'version'or 'view'of the hotel, since this user normally wouldn't/shouldn't be granted permissions to replace content for a hotel on a different organization's 'view'or 'version' of the same hotel
  • to see the user’s original content
    • kuni katsuya
       
      this implies that *at least* one version of such (temporarily) replaceable content needs to be managed/maintaned to allow reverting what if, deliberately, ignorantly or maliciously, a user replaces the same piece of--textual or any type, really--content for this hotel n times? will all n versions be required to be managed as an undo history? the user's ''original content'' might have been version 1, but equally might have been 1 mean: - previous version of the content, regardless of which user - initial version of that content attached to the hotel regardless of which user created/updated it and ignoring which organization owns it?, or, -
kuni katsuya

Edit Permissions - VFM Leonardo JIRA - 0 views

  • Edit Issues
  • Administer Projects
  • Schedule Issues
    • kuni katsuya
       
      required for: - ranking issues (in backlog) https://confluence.atlassian.com/display/GH060/Ranking+an+Issue
  • ...25 more annotations...
  • Administer Projects
  • Administer Projects
  • Project Role (Product Owner)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master)
  • Project Role (Product Owner)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master)
  • Single User (anton.marinov)
  • Single User (felix.zhuang)
  • Single User (jason.ibele)
  • Single User (cuneyt.tuna)
  • Project Role (Product Owner)
  • Project Role (Scrum Master)
  • Project Role (Scrum Master) (
  • Project Role (Scrum Master)
  • Single User (parth.upadhye)
  • Project Role (Scrum Master)
  • Project Role (Product Owner)
  • Project Role (Product Owner)
  • Project Role (Scrum Master)
kuni katsuya

Frequently Answered Questions (FAQ) - 0 views

  • 1.3.What Java and Spring Framework versions are required?
  • Spring Security 3.0 and 3.1 require at least JDK 1.5
  • and also require Spring 3.0.3 as a minimum
kuni katsuya

Enterprise Architect - Resources - Model Driven Generation (MDG) Technologies - 0 views

  • Model Driven Generation (MDG) Technologies
  • MDG Technologies allow users to extend Enterprise Architect's modeling capabilities to specific domains and notations. MDG Technologies seamlessly plug into Enterprise Architect to provide additional toolboxes, UML profiles, patterns, templates and other modeling resources.
  • Free MDG Technology downloads for Enterprise Architect:
  • ...12 more annotations...
  • EJB MDG Technology for Enterprise Java Beans allows the user to model EJB entities and EJB sessions, complete with UML profiles for modeling EJB, EJB patterns and Code Management. (requires Enterprise Architect 4.1 or later)
  • ICONIX AGILE DDT ICONIX Agile Developer - Design-Driven Testing (DDT) streamlines the ICONIX modeling process, providing: Convenient modeling of robustness diagrams Automatic generation of sequence diagram structures from robustness diagrams Transformation of robustness control elements to test diagrams Transformation of sequence diagram elements to test diagrams Transformation of requirement diagrams to test diagrams Transformation between test cases and test classes. (JUnit & NUnit) Built-in model validation rules for ICONIX robustness diagrams (requires Enterprise Architect 7.5 or later)
  • Testing MDG Technology for Testing helps users to rapidly model a wide range of testing procedures including component testing, SUT, Test Cases and more. (requires Enterprise Architect 4.1 or later)
  • Instructions for loading an MDG Technology EXE file: Download and run the .exe file to install the MDG technology. Open Enterprise Architect. Select from the Main Menu Add-Ins | XYZ Technology | Load.
  • Built-in MDG Technologies: Most of the MDG Technologies provided by Sparx Systems are built into Enterprise Architect directly. Depending on your edition of Enterprise Architect, some or all of the following MDG Technologies will be available:
  • Gang of Four Patterns
  • Mind Mapping
  • Web Modeling
  • Data Flow (DFD)
  • Entity-Relationship (ERD)
  • Business Rule Model
  • BPMN™
kuni katsuya

Threats - salesforce.com - 0 views

  • Security Best Practices Webinar for All Salesforce.com Customers
  • Designate a security contact within your organization so that salesforce.com can more effectively communicate with you
  • Consider using other two-factor authentication techniques
  • ...14 more annotations...
  • activate IP range restrictions
  • Implement IP Restrictions in Salesforce.com
  • Two-Factor Authentication
  • second-level authorization, including requiring secure IT tokens
  • does not protect against “man-in-the-middle” attacks, where messages are intercepted
  • applications that may be integrated with salesforce.com are not protected by two-factor authentication
  • Strengthen Password Policies
    • kuni katsuya
       
      salesforce.com password policies: - password expiry period - password history (reuse) enforcement - minimum password length - password complexity requirement - forgotten password hint question requirement
  • Require Secure Sessions
  • mandating that all sessions are encrypted and secure
  • Decrease Session Timeout Thresholds
  • Identify a Primary Security Contact
  • identify a person in your company who is responsible for application security
  • should have a thorough understanding of your security policies
  • single point of contact for salesforce.com
kuni katsuya

UML tools for software development and Modelling - Enterprise Architect Full Lifecycle ... - 0 views

  • EA User Guide (pdf)
  • Reference Booklets
  • Enterprise Architect Online Help
  • ...8 more annotations...
  • Tutorials All Tutorials UML Tutorials UML 2.1 Tutorial UML Tutorial - Part 1 Intro UML Tutorial - Part 2 Intro The Business Process Model The Component Model The Dynamic Model The Logical Model The Physical Model The Use Case Model UML Database Modeling Enterprise Architect Tutorials Creating Strategic Models Diagram Filters BPEL: Step by Step Guide Resource Management Testing Management Traceability RTF Documentation Use Case Metrics Structured Use Case Scenarios
  • Video Demonstrations All Videos Getting Started Requirements Management Modeling & Productivity Tools Code Engineering and the Debug Workbench Version Control Integration (Eclipse, Visual Studio, TFS)
  • UML Tutorial - Structure UML Tutorial - Behavior The Business Process Model Deployment of EA MDA Overview Rich-Text (RTF) Reporting Version Control Integration Requirements Management
  • White Papers & E-Books
  • Roles Business Analyst Database Administrator Deployment & Rollout Developer Project Manager Software Architects Software Engineer Technology Developer Testers
  • Solutions
  • MDG Technologies MDG Technologies EJB Technology.xml Testing Technology.xml
  • UML Profiles & Patterns UML Patterns UML Patterns Create UML Patterns Import UML Patterns Use UML Patterns UML Profiles UML Profiles: Introduction UML Profile for SPEM XML Schema (XSD) Generation Web Modeling Profile Eriksson-Penker Business Extensions Open Distributed Processing (UML4ODP)
kuni katsuya

Lean service architectures with Java EE 6 - JavaWorld - 0 views

  • DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.
  • With JDK 1.5 and the advent of generics, it is possible to build and deploy a generic, convenient, and typesafe DAO once and reuse it from variety of services
  •  
    DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.
kuni katsuya

TH02-EP02-US004 - VFML Admin, Org Mgmt, Sync Properties - Projects - Confluence - 0 views

  • using EXCC
    • kuni katsuya
       
      why is excc required as the mechanism?
  • sync properties
    • kuni katsuya
       
      sync meaning: a. ensuring that chain-hotel relationships based on icpm data is represented the same way in the cube node structure? (eg. which hotels belong under which chains, and to keep dynamically/automatically updated as hotels are added/removed from chains) 2. or...?
  • As a VFML user
    • kuni katsuya
       
      implies restriction of this action via authorization controls (ie. required vs granted permissions)
  • ...1 more annotation...
  • maintain an accurate listing of properties in an org
    • kuni katsuya
       
      ie. cube node-org-chain tree reflects icpm relationships exactly & always
kuni katsuya

Interface naming in Java - Stack Overflow - 0 views

  • interfaces define
  • capabilities
    • kuni katsuya
       
      this is one sensible interface naming option, if the interface encapsulates a cohesive set of behaviors and yes, compared to blindly following the meaningless I+ convention, it requires some thought, but thinking of an appropriate name also forces you to (re)consider the interface's primary responsibility and how it fits into the overall design imho, a class diagram for a domain model should be almost fluently readable english
  • not types
  • ...16 more annotations...
  • Comparable
  • Runnable
  • Serializable
  • Sometimes an Adjective doesn't make sense, but I'd still generally be using interfaces to model behavior, actions, capabilities, properties, etc,... not types.
  • Also, If you were really only going to make one User and call it User then what's the point of also having an IUser interface?
    • kuni katsuya
       
      another anti-pattern... blindly create an interface for every class, even if there's only one implementation!! arrgghhhh! consider introducing an interface when there are 2-3 well-distinguished, concrete implementations required
  • if you are going to have a few different types of users that need to implement a common interface, what does appending an "I" to the interface save you in choosing names of the implementations?
  • prefer not to use a prefix on interfaces:
  • hurts readability.
  • interfaces names should be as short and pleasant as possible
  • Implementing classes should be uglier to discourage their use.
    • kuni katsuya
       
      but they don't *have* to be ugly, like BlahImpl for specialized implementations, use descriptive adjective-noun combos
  • Code using an instance of some type should never, ever care if that type is an interface or a class
  • exposing such a detail in the name of the type is pointless and harmful to understanding
  • several reasons Java does not generally use the IUser convention.
  • should not have to know whether the client is using an interface or an implementation class
  • Java naming convention prefers longer names with actual meanings to Hungarian-style prefixes
  • Interface naming in Java [closed]
  •  
    "have interfaces define"
kuni katsuya

Stephen Colebourne's blog: Javadoc coding standards - 0 views

  • Javadoc coding standards
  • explain some of the rationale for some of my choices
  • this is more about the formatting of Javadoc, than the content of Javadoc
  • ...63 more annotations...
  • Each of the guidelines below consists of a short description of the rule and an explanation
  • Write Javadoc to be read as source code
  • Making Javadoc readable as source code
  • Public and protected
  • All public and protected methods should be fully defined with Javadoc
  • Package and private methods do not have to be, but may
  • benefit from it.
    • kuni katsuya
       
      think of it as internal design documentation when you revisit this code 8 months from now: - based on nothing but your well-chosen ;) package/class/method/variable names, will you recall all of your current design intentions and rationale? likely not - when you hand-off this code to another software engineer, how easy will it be to mostly rtfm? will you have to waste time preparing design/implementation notes specifically for the hand-off? if this is the case because the code is unreadable and not self-guiding and there's not already at least high level design notes in a wiki, you're doing it wrong!
  • If a method is overridden in a subclass, Javadoc should only be present if it says something distinct to the original definition of the method
    • kuni katsuya
       
      ie. don't just copy-paste the javadoc from the superclass. that's mindless and pointless monkey work
  • Use the standard style for the Javadoc comment
  • Do not use '**/' at the end of the Javadoc
  • Use simple HTML tags, not valid XHTML
  • XHTML adds many extra tags that make the Javadoc harder to read as source code
  • Use a single <p> tag between paragraphs
  • Place a single <p> tag on the blank line between paragraphs:
    • kuni katsuya
       
      this at least makes the paragraph breaks wysiwygísh and somewhat easier to read
  • Use a single <li> tag for items in a list
  • place a single <li> tag at the start of the line and no closing tag
  • Define a punchy first sentence
  • it has the responsibility of summing up the method or class to readers scanning the class or package
  • the first sentence should be
  • clear and punchy, and generally short
  • use the third person form at the start
  • Avoid the second person form, such as "Get the foo"
  • Use "this" to refer to an instance of the class
  • When referring to an instance of the class being documented, use "this" to reference it.
  • Aim for short single line sentences
  • Wherever possible, make Javadoc sentences fit on a single line
  • favouring between 80 and 120 characters
  • Use @link and @code wisely
  • @link feature creates a visible hyperlink in generated Javadoc to the target
  • @code feature provides a section of fixed-width font, ideal for references to methods and class names
  • Only use @link on the first reference to a specific class or method
  • Use @code for subsequent references.
  • This avoids excessive hyperlinks cluttering up the Javadoc
  • Never use @link in the first sentence
  • Always use @code in the first sentence if necessary
  • Adding a hyperlink in that first sentence makes the higher level documentation more confusing
  • Do not use @code for null, true or false
  • Adding @code for every occurrence is a burden to both the reader and writer of the Javadoc and adds no real value.
  • Use @param, @return and @throws
  • @param entries should be specified in the same order as the parameters
  • @return should be after the @param entries
  • followed by @throws.
  • Use @param for generics
  • correct approach is an @param tag with the parameter name of <T> where T is the type parameter name.
  • Use one blank line before @param
  • This aids readability in source code.
  • Treat @param and @return as a phrase
  • They should start with a lower case letter, typically using the word "the". They should not end with a dot. This aids readability in source code and when generated.
  • treated as phrases rather than complete sentences
  • Treat @throws as an if clause
  • phrase describing the condition
  • Define null-handling for all parameters and return types
    • kuni katsuya
       
      ideally, if the method in question has any specified/required pre and/or post conditions, they should be noted in the javadoc, not *just* null handling also, there are cleaner ways to design around this type of old school null handling hackage
  • methods should define their null-tolerance in the @param or @return
  • standard forms expressing this
  • "not null"
  • "may be null"
  • "null treated as xxx"
    • kuni katsuya
       
      DO NOT DO THIS this is just bad design
  • "null returns xxx"
    • kuni katsuya
       
      this might also stink of poor design ymmv
  • In general the behaviour of the passed in null should be defined
  • Specifications require implementation notes
  • Avoid @author
  • source control system is in a much better position to record authors
  • This wastes everyone's time and decreases the overall value of the documentation. When you have nothing useful to say, say nothing!
    • kuni katsuya
       
      likewise with javadoc on things like default constructors /**  * Creates an instance of SomeClass  */ public SomeClass() {} is equally useless and unnecessarily clutters up the source code
kuni katsuya

Access control - Wikipedia, the free encyclopedia - 0 views

  • Computer security
  • authentication, authorization and audit
  • In any access control model, the entities that can perform actions in the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects
  • ...39 more annotations...
  • Principle of least privilege
  • object-capability model, any software entity can potentially act as both a subject and object
  • Access control models used by current systems tend to fall into one of two classes:
  • those based on capabilities
  • those based on access control lists (ACLs)
  • Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a group of subjects (often the group is itself modeled as a subject)
  • identification and authentication determine who can log on to a system, and the association of users with the software subjects that they are able to control as a result of logging in; authorization determines what a subject can do; accountability identifies what a subject (or all subjects associated with a user) did.
  • Authorization determines what a subject can do on the system
  • Authorization
  • Access control models
  • categorized as either discretionary or non-discretionary
  • three most widely recognized models are
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Role Based Access Control (RBAC)
  • Attribute-based access control
  • Discretionary access control
  • Discretionary access control (DAC) is a policy determined by the owner of an object. The owner decides who is allowed to access the object and what privileges they have.
  • Every object in the system has an owner
  • access policy for an object is determined by its owner
  • DAC systems, each object's initial owner is the subject that caused it to be created
  • Mandatory access control
  • Mandatory access control refers to allowing access to a resource
  • if and only if rules exist
  • that allow a given user to access the resource
  • Management is often simplified (over what can be required) if the information can be protected using
  • hierarchical access control
  • or by implementing sensitivity labels.
  • Sensitivity labels
  • A subject's sensitivity label specifies its
  • level of trust
  • level of trust required for access
  • subject must have a sensitivity level equal to or higher than the requested object
  • Role-based access control
  • Role-based access control (RBAC) is an
  • access policy
  • determined by the system
  • not the owner
  • Access control
kuni katsuya

Graphical Eclipse FAQs - Eclipsepedia - 0 views

  • How do I alter my package representation so that parent packages are housing child packages? 1. Click on the dropdown menu on the Package Explorer view. Go to the 'Package Representation' submenu and then click on 'Hierarchical'.
  • PDE I get an unhandled event loop exception in my console. What gives? 1. Open up the run dialog via the dropdown toolbar item.
  • 2. Select your Eclipse Application launch configuration. Go into the 'Arguments' tab and then append '-consoleLog' as an argument and then try running your application again.
  • ...3 more annotations...
  • 2. You should now see your packages presented in a tree like structure.
  • How do I not install a plug-in's extraneous dependency when I'm in the Update Manager? 1. Are you seeing a screen similar to the one where the plug-in you are installing is asking for some other plug-in? 2. Expand the section by clicking on the arrow. Keep expanding until you see everything and then tick off the "additional dependencies" that you don't want. 3. Now you can install the plug-in without installing other things.
  • I have just installed a plug-in but I do not see any indication of it in my workspace. What do I do? 1. Did you try restarting Eclipse with the -clean argument?
  •  
    How do I alter my package representation so that parent packages are housing child packages? 1. Click on the dropdown menu on the Package Explorer view. Go to the 'Package Representation' submenu and then click on 'Hierarchical'.
kuni katsuya

Quick start with GraniteDS | Granite Data Services - 0 views

  • install the GraniteDS wizard and builder plugins in Eclipse
  • graniteds-tide-cdi-jpa
  • you don’t need to have a Flex SDK installed as it will be retrieved from the Maven repository
  • ...12 more annotations...
  • 3 separate projects: a Java project, a Flex project and a Webapp project.
  • GraniteDS archetypes
  • archetypeGroupId: org.graniteds.archetypes archetypeVersion: 1.1.0.GA archetypeArtifactId:
  • Maven 3.x required
  • mvn archetype:generate    -DarchetypeGroupId=org.graniteds.archetypes    -DarchetypeArtifactId=graniteds-tide-spring-jpa-hibernate    -DarchetypeVersion=1.1.0.GA    -DgroupId=org.example    -DartifactId=springgds    -Dversion=1.0-SNAPSHOT
  • cd springgdsmvn clean package
  • build the project
  • CDI archetype requires a Java EE 6 server and uses an embedded GlassFish
  • cd webappmvn embedded-glassfish:run
  • With the Eclipse Maven integration (the M2E plugin), you can simply choose one of the archetypes when doing New Maven Project.
  • mvn war:war
  • two very easy ways to quickly create a new GraniteDS project
kuni katsuya

Selling Weld and EE6 | Weld | JBoss Community - 0 views

  • regarding the issue of selling Weld and EE6 to developers/shops....
  • How bout a JdbcTemplate Spring equivalent in the case of projects using legacy db schemas
  • portable extension to Weld
  • ...32 more annotations...
  • William Drai
  • Honestly I don't see any value in switching to CDI if it is
  • to reproduce the same awful patterns
  • please not this Dao/Template mess
  • Gavin King
  • Their template pattern is a solution in search of a problem
    • kuni katsuya
       
      gold! :)
  • to reproduce the same awful patterns
  • please not this Dao/Template mess
  • Because, of course, there are no other well-known patterns for dealing with boiler-plate cleanup code and connection leaks.
  • This is exactly the kind of
  • brain-damage that Spring does to people!
    • kuni katsuya
       
      platinum!!!
  • It gives people a
  • half-assed solution
  • and somehow shuts down their brains so they
  • stop asking themselves how this solution could be improved upon
  • It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.
  • but that might be too high-level for your taste. Their are other, less-abstract options.
  • exception handling, this is one area where Spring does a good job: "The Spring Framework's handling of SQLException is one of its most useful features in terms of enabling easier JDBC development and maintenance. The Spring Framework provides JDBC support that abstracts SQLException and provides a DAO-friendly, unchecked exception hierarchy."
  • Utter nonsense and dishonest false advertising
  • Automatic connection closing (and other boiler-plate code) is obviously a hard requirement to be handled by the fwk.
  • Pffffff. It's a trivial requirement which I can solve in my framework with two lines of code in a @Disposes method. Did you see any connection handling in the code above?
  • I mean, seriously guys. The Spring stuff is trivial and not even very elegant. I guess it's easier for me to see that, since I spent half my career thinking about data access and designing data access APIs. But even so...
  • I don't understand. You hate the ability to write typesafw SQL that much?
  • Gavin King
  • Methods with long argument lists are a code smell.
  • It's something Spring copied from Hibernate 1.x, back in the days before varargs
  • It's something we removed in Hibernate2 and JPA.
  • there are a bunch of people
  • who don't want to use JPA.
  • They don't understand, or see the value of, using managed objects to represent their persistent data.
  • Um. Why? Why would that be a bad thing? I imagine that any app with 1000 queries has tens of thousands of classes already. What's the problem? Why is defining a class worse than writing a method?
  • Are you working from some totally bizarre metric where you measure code quality by number of classes?
kuni katsuya

[#ANN-140] Discriminator column not supported with JOINED strategy - Hibernate JIRA - 0 views

  • Hibernate does not need a discriminator
  • because Hibernate is better than these other inferior implementations
  • It is allowed for
  • ...2 more annotations...
  • inferior implementations
  • of the JOINED mapping strategy which require a discriminator
kuni katsuya

Chapter 5. Basic O/R Mapping - 0 views

  • 5.1.6.2. Joined subclass strategy
  • A discriminator column is not required for this mapping strategy
  •  
    "5.1.6.2. Joined subclass strategy"
kuni katsuya

AnemicDomainModel - 0 views

  • AnemicDomainModel
  • Eric Evans
  • basic symptom of an Anemic Domain Model
  • ...40 more annotations...
  • The catch comes when you look at the
  • behavior
  • there is hardly any behavior on these objects, making them little more than bags of getters and setters
  • I was chatting with
    • kuni katsuya
       
      note, the 'i' here, is mr. MARTIN FOWLER!! and of course, eric evans hails from domain driven design fame
  • fundamental horror
  • it's so contrary to the basic idea of object-oriented design
  • combine
  • data and process together
  • procedural style design
  • completely miss the point of what object-oriented design is all about
  • It's also worth emphasizing that putting behavior into the domain objects
  • should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities
  • logic that should be in a domain object is domain logic
  • validations
  • calculations
  • business rules
  • One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer
  • this isn't an argument to make the domain model
  • void of behavior
  • service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
  • does not contain business rules or knowledge, but
  • only coordinates
  • tasks and delegates work to
  • collaborations of domain objects
  • in the next layer down
  • can have state that reflects the
  • progress of a task
  • for the user or the program
  • Domain Layer
  • Application Layer
  • Service Layer
  • Responsible for
  • representing concepts of the business
  • business rules
  • This layer is the heart of business software
    • kuni katsuya
       
      ... and has the *most value* to an organization investing in writing their own software infrastructure software (eg. user interface, orm, application server-related frameworks) or plumbing code should be treated as commodities where possible, unless, the business consciously decides that a custom, home-grown implementation is absolutely required for patenting or other differentiation reasons and/or that no existing off-the-shelf solution can be used but these cases should be rare! do not blindly fall for the not-invented-here syndrome
  • all the key logic lies in the domain layer
  • I don't know why this anti-pattern is so common
  • if they come from a
  • data background
    • kuni katsuya
       
      this is why during every sprint, i reiterate that the data model up approach to designing the system is OH SO WRONG but nobody listens
  • J2EE's Entity Beans
    • kuni katsuya
       
      damn baggage from  eons ago!!!
kuni katsuya

Top 10 Lessons Learned From 10 Years in Agile | Agile Zone - 0 views

  • Top 10 Lessons Learned From 10 Years in Agile
  • 1.  Simplicity is Sophistication.  
  • 2.  Define your Rhythm.  
  • ...18 more annotations...
  • start cutting down on wasted meeting time
  • 3. Agile is Fundamentally About Discipline.  
  • areas of planning, unit testing, test driven development, continuous integration, and test automation.
  • 4.  Software is Hard to Scale, Agile is Not.  
  • Focus on business goals
  • 5.  Think of the Big Picture.   
  • success requires a
  • consideration of the system as a whole
  • before making changes to its parts, or else the change will likely be fraught with risk.
  • 6.  Lose the Religion  
  • adapt agile to your need.
  • 7. Continuous Focus on Business Value.
  • get caught in the weeds of a technical story's delivery and velocity at the expense of overall business value, company and project goals
  • 8. Agile - It's Not Just For Software Anymore.
  • 9. Continuous Planning. 
  • Plan on a daily basis if possible
  • Keep your focus on maximizing value
  • 10.  Doing agile and being agile aren’t the same.
1 - 20 of 58 Next › Last »
Showing 20 items per page