In Mysql we can get last increment id or inserted Id by using the following query
SELECT LAST_INSERT_ID()
In Mysql we can get last increment id or inserted Id by using the following query
SELECT LAST_INSERT_ID()
MailTo Syntax
PLEASE NOTE:
The MailTo command can do more than enter a single e-mail address in the "Send To" field while activating your e-mail program. It can also:
| Feature | | Syntax |
| Address message to multiple recipients | , (comma separating e-mail addresses) | |
| Add entry in the "Subject" field | subject=Subject Field Text | |
| Add entry in the "Copy To" or "CC" field | cc=id@internet.node | |
| Add entry in the "Blind Copy To" or "BCC" field | bcc=id@internet.node | |
| Add entry in the "Body" field | body=Your message here |
Notes:
" " (beginning and ending double quotes) are necessary if any spaces are used
Mailto parameter should be preceded by "?" for the first or only parameter and "&" for second and subsequent parameter.
Some examples, with actual HTML Code included, follow:
<a href="mailto:astark1@unl.edu">
MailTo with Multiple Recipients
<a href="mailto:astark1@unl.edu,ASTARK1@UNL.EDU">
<a href="mailto:astark1@unl.edu?subject=Comments from MailTo Syntax Page">
<a href="mailto:astark1@unl.edu?cc=ASTARK1@UNL.EDU">
<a href="mailto:astark1@unl.edu?bcc=ASTARK1@UNL.EDU">
MailTo with message already started in Body
<a href="mailto:astark1@unl.edu?body=I am having trouble finding information on ">
MailTo with multiline message in Body
<a href="mailto:astark1@unl.edu?body=The message's first paragraph.%0A%0aSecond paragraph.%0A%0AThird Paragraph.">
NOTE: Use "%0A" for a new line, use "%0A%0A" for a new line preceded by a blank line.
Features may be used in combination
MailTo with Subject, a Recipient, a Copy and a Blind Copy
<a href="mailto:astark1@unl.edu?subject=MailTo Comments&cc=ASTARK1@UNL.EDU&bcc=id@internet.node">
Remember to use only one ? (question mark), when providing multiple entries beyond e-mail address
Javascript is becoming increasingly popular on websites, from loading dynamic data via AJAX to adding special
effects to your page.
Unfortunately, these features come at a price: you must often rely on heavy Javascript libraries that can add dozens
or even hundreds of kilobytes to your page.
Users hate waiting, so here are a few techniques you can use to trim down your sites.
Like any optimization technique, it helps to measure and figure out what parts are taking the longest. You might find
that your images and HTML outweigh your scripts. Here's a few ways to investigate:
1. The Firefox web-developer toolbar lets you see a breakdown of file sizes for a page (Right Click > Web
Developer > Information > View Document Size). Look at the breakdown and see what is eating the majority if
your bandwidth, and which files:

2. The Firebug Plugin also shows a breakdown of files - just go to the "Net" tab. You can also filter by file type:

3. OctaGate SiteTimer gives a clean, online chart of how long each file takes to download:

Disgusted by the bloat? Decided your javascript needs to go? Let's do it.
First, you can try to make the javascript file smaller itself. There are lots of utilities to "crunch" your files by
removing whitespace and comments.
You can do this, but these tools can be finnicky and may make unwanted changes if your code isn't formatted
properly. Here's what you can do:
1. Run JSLint (online or downloadable version) to analyze your code and make sure it is well-formatted.
2. Use Rhino to compress your javascript. There are some online packers, but Rhino actually analyzes your source
code so it has a low chance of changing it as it compresses, and it is scriptable.
Install Rhino (it requires Java), then run it from the command-line:
java -jar custom_rhino.jar -c myfile.js > myfile.js.packed 2>&1
This compresses myfile.js and spits it out into myfile.js.packed. Rhino will remove spaces, comments and shorten
variable names where appropriate. The "2>&1″ part means "redirect standard error to the same location as the
output", so you'll see any error messages inside the packed file itself (cool, eh? Learn more here.).
Using Rhino, I pack the original javascript and deploy the packed version to my website.
Debugging compressed Javascript can be really difficult. I suggest creating a "debug" version of your page that
references the original files. Once you test it and get the page working, pack it, test the packed version, and then
deploy.
If you have a unit testing framework like jsunit, it shouldn't be hard to test the packed version.
Because typing these commands over and over can be tedious, you'll probably want to create a script to run the
packing commands. This .bat file will compress every .js file and create .js.packed:
compress_js.bat:
for /F %%F in ('dir /b *.js') do java -jar custom_rhino.jar -c %%F > %%F.packed 2>&1
Of course, you can use a better language like perl or bash to make this suit your needs.
Place your javascript at the end of your HTML file if possible. Notice how Google analytics and other stat
tracking software wants to be right before the closing </body> tag.
This allows the majority of page content (like images, tables, text) to be loaded and rendered first. The user sees
content loading, so the page looks responsive. At this point, the heavy javascripts can begin loading near the end.
I used to have all my javascript crammed into the <head> section, but this was unnecessary. Only core files that
are absolutely needed in the beginning of the page load should be there. The rest, like cool menu effects,
transitions, etc. can be loaded later. You want the page to appear responsive (i.e., something is loading) up front.
An AJAX pattern is to load javascript dynamically, or when the user runs a feature that requires your script.
You can load an arbitrary javascript file from any domain using the following import function:
function $import(src){
var scriptElem = document.createElement('script');
scriptElem.setAttribute('src',src);
scriptElem.setAttribute('type','text/javascript');
document.getElementsByTagName('head')[0].appendChild(scriptElem);
}
// import with a random query parameter to avoid caching
function $importNoCache(src){
var ms = new Date().getTime().toString();
var seed = "?" + ms;
$import(src + seed);
}
The function $import('http://example.com/myfile.js') will add an element to the head of your document, just like
including the file directly. The $importNoCache version adds a timestamp to the request to force your browser to
get a new copy.
To test whether a file has fully loaded, you can do something like
if (myfunction){
// loaded
}
else{ // not loaded yet
$import('http://www.example.com/myfile.js');
}
There is an AJAX version as well but I prefer this one because it is simpler and works for files in any domain.
Rather than loading your javascript on-demand (which can cause a gap), load your script in the background,
after a delay. Use something like
var delay = 5;
setTimeout("loadExtraFiles();", delay * 1000);
This will call loadExtraFiles() after 5 seconds, which should load the files you need (using $import). You can even
have a function at the end of these imported files that does whatever initialization is needed (or calls an existing
function to do the initialization).
The benefit of this is that you still get a fast initial page load, and users don't have a pause when they want to use
advanced features.
In the case of InstaCalc, there are heavy charting libraries that aren't used that often. I'm currently testing a method
to delay chart loading by a few seconds while the core functionality remains available from the beginning. You may
need to refactor your code to deal with delayed loading of components. Some ideas are to use SetTimeout to poll
the loading status periodically, or having a function called at the end of your included script to tell the main program
the script has been loaded.
Another approach is to explicitly set the browser's cache expiration. In order to do this, you'll need access to PHP
so you can send back certain headers.
Rename myfile.js to myfile.js.php and add the following lines to the top:
<?php
header("Content-type: text/javascript; charset: UTF-8");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 3;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);
?>
In this case, the cache will expire in (60 * 60 * 24 * 3) seconds or 3 days. Be careful with using this for your own
files, especially if they are under development. I'd suggest caching library files that you won't change often.
If you accidentally cache something for too long, you can use the $importNoCache trick to add a datestamp like
"myfile.js?123456″ to your request (which is ignored). Because the filename is different, the browser will request a
new version.
Setting the browser cache doesn't speed up the initial download, but can help if your site references the same files
on multiple pages, or for repeat visitors.
A great method I initially forgot is merging several javascript files into one. Your browser can only have so many
connections to a website open at a time — given the overhead to set up each connection, it makes sense to
combine several small scripts into a larger one.
But you don't have to combine files manually! Use a script to merge the files — check out part 2 for an example
script to do this. Giant files are difficult to edit - it's nice to break your library into smaller components that can be
combined later, just like you break up a C program into smaller modules.
Probably not. Although some browsers can accept compressed javascript (myfile.js.gz) or files returned with the
"gzip" encoding header, this behavior is not consistent between browsers and can be problematic.
If you're an expert, feel free to experiment, but for the majority of us I don't think it's worth the effort or potential
headache.
Once you've performed the techniques above, recheck your page size using the tools above to see the
before-and-after difference.
I'm not an expert on these methods — I'm learning as I go. Here are some additional references to dive in deeper:
zahnarzt | zeitarbeit | buchhandlung | bekleidung | apotheke |
aerobic | paketshop | marketing tool | marketing tools | SEO Blog
—
JavaScripts Guides: Beginner, Advanced
JavaScripts Tutorials: Beginner, Advanced
Project Caroline Overview
Project Caroline is developing a horizontally scalable platform for the development and deployment of Internet services. The initial design center is to make the platform available as a utility, where a pool of virtualized resources is shared between many customers each with one or more services. Through the utility model services can dynamically flex their usage of the platform's distributed resources up and down, matching usage to observed load. The horizontal scalability of the platform allows for the efficient delivery of resources and supports a pay-for-use (verses pay-for-capacity) billing model. Customers of the utility are isolated from each other and mechanisms are provided for the isolation of services.
The primary resource provided by Project Caroline is a set of horizontally scaled machines for running customer processes. Customers specify for each process the program to run, what networked file systems it should have access to, and IP addresses it should be reachable at. The platform takes care of the details of finding a machine for the process to run on, configuring the machine, network, and Internet connectivity. Operating system-level virtualization is used to isolate processes sharing the same physical machine while keeping per-process overhead low. Customer programs are expressed in languages like Java byte code, perl, and python that provide OS and instruction set independence. Other resources include IP sub-nets, network file systems, databases, external IP addresses, L4 and L7 load balancers, and DNS bindings. Applications can allocate, configure, and release these resources using the platform API. Through the platform API, applications can acquire and release resources in seconds.
In addition to the platform API, various tools and components have been layered on top of the platform API, including: cash, a Ruby-derived interactive shell; a standalone GUI and a NetBeans plug-in for direct manipulation of Project Caroline resources; a set of (J)Ruby centric tools for using Project Caroline; Apache Ant tasks for easily automating the creation and management of Project Caroline resources; and macro-components such as the Project Caroline Web Server (based on Project GlassFish v3) which automates setup and management of a horizontally-scaled web tier.
It needs sometimes to exactly mimic Oracle’s ROWNUM where is no possibility to initiate a counter in previous statement by SET @rownum:=0;.
It is still possible in a single SQL.
SELECT @rownum:=@rownum+1 rownum, t.*FROM (SELECT @rownum:=0) r, mytable t;
| | java.lang.Object.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; | |
| I keep getting this error: javax.faces.FacesException: java.lang.Object.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; caused by: org.apache.jasper.JasperException: java.lang.Object.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; caused by: javax.servlet.ServletException: java.lang.Object.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; caused by: java.lang.NoSuchMethodError: java.lang.Object.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; After using the web client for a few minutes. | ||
This exception is usually due to the JVM not being run with the -server option. The startup.bat/sh scripts set up the appropriate JAVA_OPTS.
Estimation of features is a critical part of the software development process, especially if you are using an Agile methodology. The ability to accurately estimate features is an often overlooked skill that every developer should have.
As a project engineer, responsible for making sure that we set realistic project timelines and that we actually carry those out. Managing expectations is one of main responsibilities. This is where Agile is so nice — as long as you do it right.
When we start on a new project, usually one of the first things that happens is meeting with the client or whoever is sponsoring the project.
In these initial meetings, at some point we will probably be asked one of two things:
1) how long will it take to accomplish X?
2) how much can we get done before X (some date)?