I was trying to solve a problem of resetting a focus if the parent changes. I had different buttons that show the same .mxml-form but with different data. The problem was that I needed the focus to be on the first date-field whenever the form is shown so that the user can begin typing data right away.
<mx:HBox>
<mx:Button id="noData" click="showPanelWithNoData()" />
<mx:Button id="someData" click="showPanelWithSomeData()" />
<mx:Button id="withData" click="showPanelWithData()" />
<myCustomForm:DataForm width="100%" />
</mx:HBox>
So for each time one of the buttons is pushed I need the focus to be on myDate-field. To solve the problem I used “updateComplete“-property of the field.
DataForm.mxml
<?xml version="1.0" encoding="utf-8"?>
<DataForm
xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
import mx.managers.FocusManager;
private function resetFocus():void {
if (focusManager != null && myDate.focusManager != null) {
focusManager.setFocus(myDate);
}
}
]]>
</mx:Script>
<mx:FormItem>
<mx:TextField id="myDate"
updateComplete="resetFocus()"/>
</mx:FormItem>
</DataForm>
1. Painters need to start painting the interiors before the house foundation is started on.
2. Carpenters must finish the roof before the walls are strong enough to support it.
3. The exterior should look like gold, but in reality made of mud.
4. Skip the foundation. Nobody will ever care to take a look there, or have access there.
5. The electricity, water pipes and waste disposal can go through the same pipe.
6. When the house is almost finished, the owner wants to move a couple of walls, add some floors, at no extra cost.
7. When the house is “finished”, the owner must expect to patch it up when it rains, apply service personell monthly and within 2 years the house it out of date.
When porting projects from Visual Studio 2008 or earlier to Visual Studio 2010, and you’re using boost::shared_ptr or other features present in TR1, there will be conflicts. Boost has their own implementation of shared_ptr in boost::shared_ptr and with VS2010 they have put shared_ptr in std::tr1 and they have made shared_ptr available through std::shared_ptr. When using using namespace std; and using namespace boost; there will be ambiguities.
To disable the C++0x/TR1 headers from VS2010 and use the boost implementation, define _HAS_CPP0X=0 in the project settings for your VS2010 project.
Edit: The define was in error set to _HAS_CPP0X=1. It should be _HAS_CPP0X=0 to disable TR1 headers from Visual Studio 2010.
If you need to update a column in a table than you can use different approaches:
1) To modify a datatype of the column:
alter table Person modify COLUMN_A char(2) null
2) To make a column required:
First look if the column has some constraints:
sp_helpconstraint Person
If the column has constraints than you need to drop them first:
alter table Person drop constraint FK_PERSON_REF_ADRESS
Then if you can specify a default value for the column you can drop the column and create it again:
alter table Person drop COLUMN_A
alter table Person add COLUMN_A char(2) default 0 not null
But there is not the way we always need it. In such a case we need to drop the hole table and create it again:
drop table Person
create table Person(
COLUMN_B numeric(9,0) null,
COLUMN_C char(2) not null,
COLUMN_D date not null,
COLUMN_A numeric(9,0) identity,
constraint PK_PERSON primary key (COLUMN_A),
constraint FK_PERSON_REF_ADRESS foreign key (COLUMN_B)
references Adress (COLUMN_ADRESS_A)
)
I’ve recently come to a heuristic called the Law of Demeter (LoD) or Principle of Least Knowledge that says a module should not know about the innards of the objects it manipulates. More precisely, the method of a particular class should call:
- other methods of the same class
- objects created by the method itself
- objects passed as arguments to the method
- objects held in an instance variable of the same class
And that”s all!
So the following code appears to violate the Law:
String output = obj.getContext().getOptions().getDir().getPath();
It’s easy to forget something around such a structure. This one can solve the issue:
String output = obj.getPathFromContext();
This little macro prints out user warnings to the output window in a format the “Error List” within Visual Studio will understand and parse. Taken from Stack Overflow and modified a little.
#define STRINGISE_IMPL(x) #x
#define STRINGISE(x) STRINGISE_IMPL(x)
// Use: #pragma message WARN("My message")
#if _MSC_VER
# define FILE_LINE_LINK __FILE__ "(" STRINGISE(__LINE__) ") : "
# define WARN(exp) (FILE_LINE_LINK "warning: " exp)
#else//__GNUC__ - may need other defines for different compilers
# define WARN(exp) ("WARNING: " exp)
#endif
It will produce output like this:
1>.\src\bug.cpp(82) : warning: check me
When this line is present in the source file.
#pragma message WARN("check me")
I had some difficult time understanding all the roles regarding EJB3. Here is an easy-to-remember description of these roles that I found here.
Imagine a factory producing computers:
Bean Provider:
Chip manufacturer. On the chip, there will be a label with “Warranty void if removed” the chip has the logic and the label sets a Role. If you are not authorized to repair it, warranty voids. (i.e. you cannot access the internal chip if you are not in the role of “Warranty Repair Person”.)
Application Assembler
Mainboard assembler. It takes various chips and puts them on the mainboard. If any additional resistor or cable are required, it will put everything togheter to have something that is some kind of working unit but requires additional assembling.
EJB Server Provider
The EJB Server provider is the Computer Case manufacturer providing a case with a power supply. Is a container for the mainboard
Deployer
As every computer case is different and power voltage vary country by country, the Deployer makes sure to adapt the mainboard to the working environment. In this case adjusts the Voltage on the power supply, and connects the cables. At the same time he will define who are the person allowed to repair it (i.e. provide a list of authorized repair centers)
Persistence Provider
the persistence provider could be the network card company that provides the driver to connect to a network.
System Administrator
Is the person in charge to install the operating system and do necessary configuration changes to the OS to connect to the server, and will make sure to monitor that everything is working fine.
More about Enterprise Java Beans 3.0 and Sun Certified Business Component Developer (SCBCD) certification here.
The book by Robert C. Martin “Clean Code” is a really very useful material for all programmers. You can disagree with him sometimes (as I do), but it still provides some useful notes that helped me to place my programmer experience and knowledge where they belong. Here I’ll provide some key notes that I did while reading the book and that I’d like to memorize.
What you as a programmer SHOULD DO:
1. Give everything meaningful, searchable and pronounceable names.
2. Use names that other programmers can understand. Remember that the code is for programmers, not customers.
3. Functions should be small and smaller than that.
4. Functions should do one thing. They should do it well. They should do it only.
5. The ideal number of arguments for a function is zero. Max 3.
6. Prefer exceptions to returning error codes. Create informative error messages.
7. Prefer meaningful names to comments.
8. Write JavaDoc only for public API’s.
9. Format your code. While working in a team use a single formatting style.
10. Test your code with clean tests. Remember that test code is just as important as production code.
11. Test just one concept per test.
12. Test should follow the FIRST rule:
Fast - tests should be fast.
Independent - tests should not depend on each other
Repeatable - tests should be repeatable in any environment
Self-validating – the test should have a boolean output
Timely - write unit tests before the production code.
What you as a programmer should AVOID:
1. Avoid encoding
2. Avoid duplicate code. Watch out not only duplicate functions but also duplicate functionality.
3. Avoid noisy, redundant, uninformative comments. Remember that one of the more common motivations for writing comments is bad code.
