In AS3 you can pass a constant to the compiler
-define+=CONFIG::DEBUG,true
And use it for conditional compilation like so:
CONFIG::DEBUG {
trace("This only gets compiled when debug is true.");
}
I'm looking for something like #ifndef so I can negate the value of debug and use it to conditionally add release code. The only solution I've found so far was in the conditional compilation documentation at adobe and since my debug and release configurations are mutually exclusive I don't like the idea of having both DEBUG and RELEASE constants.
Also, this format works, but I'm assuming that it's running the check at runtime which is not what I want:
if (CONFIG::DEBUG) {
//debug stuff
}
else {
//release stuff
}
I also considered doing something like this but it's still not the elegant solution I was hoping for:
-define+=CONFIG::DEBUG,true -define+=CONFIG::RELEASE,!CONFIG::DEBUG
Thanks in advance :)
This works fine and will strip out code that won't run:
if (CONFIG::DEBUG) {
//debug stuff
}
else {
//release stuff
}
BUT this will be evaluated at runtime:
if (!CONFIG::DEBUG) {
//release stuff
}
else {
//debug stuff
}
mxmlc apparently can only evaluate a literal Boolean, and not any kind of expression, including a simple not.
Use the if / else construct : the dead code will be removed by the compiler and it will not be tested at runtime. You will have only one version of your code in your swf.
If you are not sure use a decompiler or a dump tool to see what really happens.
http://apparat.googlecode.com/files/dump.zip
http://www.swftools.org/
...
While Patrick's answer fulfills the question's criteria, it does not cover all use cases. If you are in an area of code that allows you to use an if/else statement then this is a good answer. But if you are in a place where you cannot then you will need a better solution. For example, you may want to do something like this to declare a constant in a class:
private var server:String = "http://localhost/mystagingenvironment";
or for a live release:
private var server:String = "http://productionserver.com";
(this is an example and I'm not advocating this as production code).
I use xml configs and use the loadConfig+="myconfig.xml" to do my configuration instead of passing large numbers of command line params. So in the <compiler> section of your xml config:
<define>
<name>CONFIG::debug</name>
<value>false</value>
</define>
<define>
<name>CONFIG::release</name>
<value>!CONFIG::debug</value>
</define>
This works well for all use cases:
CONFIG::debug
{
private var server:String = "http://localhost/mystagingenvironment";
}
CONFIG::release
{
private var server:String = "http://productionserver.com";
}
This has the additional benefit of working consistently across applications. It also does not rely on the 'optimize' flag being true, like Patrick's answer (although I think we can assume that 99.999999% of all swfs have optimize=true, I only set it to false when the optimizer breaks my AS3).
It does have the drawback that it doesn't compile all code paths, just the ones that are included. So if you're not using a build server to create release builds and tell you when things break, be prepared for surprise errors when you do your release build ("But it compiled in debug! Crap, I need this to launch now!").
Just my two cents about Chris Hill's answer (which is the solution I also use regularly): it seems that using the loadConfig+="myconfig.xml" option makes the compiler searching for the myconfig.xml file in the Flex SDK directory whereas the -load-config+=myconfig.xml option makes it searching for the myconfig.xml file in the project's directory, which is the behavior I strongly prefer as you can then easily distribute this file with your project sources...
Related
What are the strategies to embed a unique version number in a Spring application?
I've got an app using Spring Boot and Spring Web.
Its matured enough that I want to version it and see it displayed on screen at run time.
I believe what you are looking for is generating this version number during build time (Usually by build tools like Ant, Maven or Gradle) as part of their build task chain.
I believe a quite common approach is to either put the version number into the Manifest.mf of the produced JAR and then read it, or create a file that is part of the produced JAR that can be read by your application.
Another solution would be just using Spring Boot's banner customization options described here: http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-spring-application.html#boot-features-banner
However, this will only allow you to change spring-boot banner.
I also believe that Spring Boot exposes product version that is set in Manifest.MF of your application. To achieve this you will need to make sure Implementation-Version attribute of the manifest is set.
Custom solution for access anywhere in the code
Lets assume you would like to have a version.properties file in your src/main/resources that contains your version information. It will contain placeholders instead of actual values so that these placeholders can be expanded during build time.
version=${prodVersion}
build=${prodBuild}
timestamp=${buildTimestamp}
Now that you have a file like this you need to fill it with actual data. I use Gradle so there I would make sure that processResources task which is automatically running for builds is expanding resources. Something like this should do the trick in the build.gradle file for Git-based code:
import org.codehaus.groovy.runtime.*
import org.eclipse.jgit.api.*
def getGitBranchCommit() {
try {
def git = Git.open(project.file(project.getRootProject().getProjectDir()));
def repo = git.getRepository();
def id = repo.resolve(repo.getFullBranch());
return id.abbreviate(7).name()
} catch (IOException ex) {
return "UNKNOWN"
}
}
processResources {
filesMatching("**/version.properties") {
expand (
"prodVersion": version,
"prodBuild": getGitBranchCommit(),
"buildTimestamp": DateGroovyMethods.format(new Date(), 'yyyy-MM-dd HH:mm')
)
}
}
processResources.outputs.upToDateWhen{ false }
In the code about the following is happening:
We defined a function that can take a build number out of the VCS
(in this case Git). The commit hash is limited to 7 characters.
We configure the processResources task to process
version.properties file and fill it with our variables.
prodVersion is taken from Gradle project version. It's usually set
as version in gradle.properties file (part of the general build
setup).
As a last step we ensure that it's always updated (Gradle
has some mechanics to detect if files ened to be processed
Considering you are on SVN, you will need to have a getSvnBranchCommit() method instead. You could for instance use SVNKit or similar for this.
The last thing that is missing now is reading of the file for use in your application.
This could be achieved by simply reading a classpath resource and parsing it into java.util.Properties. You could take it one step further and for instance create accessor methods specifically for each field, e.g getVersion(), getBuild(), etc.
Hope this helps a bit (even though may not be 100% applicable straight off)
Maven can be used to track the version number, e.g.:
<!-- pom.xml -->
<version>2.0.3</version>
Spring Boot can refer to the version, and expose it via REST using Actuator:
# application.properties
endpoints.info.enabled=true
info.app.version=#project.version#
Then use Ajax to render the version in the browser, for example using Polymer iron-ajax:
<!-- about-page.html -->
<iron-ajax auto url="/info" last-response="{{info}}"></iron-ajax>
Application version is: [[info.app.version]]
This will then show in the browser as:
Application version is: 2.0.3
I'm sure you've probably figured something out since this is an older question, but here's what I just did and it looks good. (Getting it into the banner requires you to duplicate a lot).
I'd recommend switching to git (it's a great SVN client too), and then using this in your build.gradle:
// https://github.com/n0mer/gradle-git-properties
plugins {
id "com.gorylenko.gradle-git-properties" version "1.4.17"
}
// http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
springBoot {
buildInfo() // create META-INF/build-info.properties
}
bootRun.dependsOn = [assemble]
And this in your SpringBoot application:
#Resource
GitProperties props;
#Resource
BuildProperties props2;
Or this way to expose those properties into the standard spring environment:
#SpringBootApplication
#PropertySources({
#PropertySource("classpath:git.properties"),
#PropertySource("classpath:META-INF/build-info.properties")
})
public class MySpringBootApplication {
and then referencing the individual properties as needed.
#Value("${git.branch}")
String gitBranch;
#Value("${build.time}")
String buildTime;
I'm working with Adobe Extendscript, which == javascript*, and I'm using the Atom JSHint package in Atom. Extendscript is the scripting framework for Adobe apps like Photoshop and After Effects. Adobe do make an IDE but it's really feeble, so I write with Atom and then switch over to "Extendscript Toolkit" to run my scripts. Anyway…
Adobe lets you use C-style preprocessor directives like #include "myUsefulFunctions.jsx" so that you can keep reusable stuff in libraries like a real programming language.
The problem is that the JSHint linter sees my C-style preprocessor directives at the top of the page, freaks out and gives up. To actually get it to lint my code I have to comment the preprocessor directives out and then remember to uncomment them before I run the code. This means at least 3 or 4 extra keystrokes each time I test, which as you all know is The. Worst. Thing. Ever.
So to save half a dozen keystrokes I've been looking into the settings for JSHint. Nothing I've found so far seems related. Is there any way of globally getting JSHint to ignore lines like #this, or locally in the file to get it to skip a line or two?
*or is it ===? I'm really confused by JS's approach to the truth.
I also tried to figure it out for a long time, until I found the best solution.
Instead of using:
#target aftereffects
You can use:
//#target aftereffects
I didn't found any documentations for the above solution.
I just found it in a script over the net, and I tried it and it worked.
And instead using:
#include "some/path/to/file.jsx"
As mentioned in the JavaScript Tools Guide:
evalFile()
$.evalFile (path[, timeout])
Loads a JavaScript script file from disk, evaluates it, and returns the result of evaluation.
path: The name and location of the file.
timeout: Optional. A number of milliseconds to wait before returning undefined, if the script cannot be evaluated. Default is 10000 milliseconds.
You can use:
$.evalFile("some/path/to/file.jsx");
The diffrence is that #include:
Includes a JavaScript source file from another location.
Inserts the contents of the named file into this file at the location
of this statement.
In jshint you can ignore lines by adding a ignore statement to the line.
#target aftereffects //jshint ignore:line
Or you can ignore whole blocks like this.
// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
/* jshint ignore:end */
(BTW the //#target aftereffects is pretty cool. Thanks for pointing that out)
I changed the JSHint package that I use, and now there's no need for workarounds.
For anyone else developing Extendscript in Atom the linter I recommend is this one: Linter-JSHint. It's a plug-in for the Atom Linter package, so you'll need to install that too.
Then once you've done that use this to ignore a block:
// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
#includepath "lib"
#include myBrilantLib.jsx
/* jshint ignore:end */
or for a single line:
ignoreThis(); // jshint ignore:line
I have a large complex ASP.net WebForm website that I'm working on a visual redesign and am trying to think of good ways to exercise all the code paths in the website so I can see how things look with the redesign.
For example lets say I have a message that only gets displayed if there is an error which rarely happens. Here is an example of what my code might look like:
if (someErrorCondition) {
someControl.Visible = true;
} else {
someOtherControl.Visible = true;
}
This might not be a good way of doing things, but this is a good example of my existing code base I have to work with.
Let us assume for the sake of simplicity that I already have a way of testing one part of the if. The problem is exercising the other part without going through a lot of trouble to setup my environment to create an error.
One idea I had was to extract someErrorCondition into a method and in that method check for some session or request key to see if I want to fake a failure. Maybe wrap it in an #if DEBUG block so that it won't be compiled for production.
Any other ideas for how I might go about testing unusual code blocks on an ASP.net website so I can make sure nothing got left out in the redesign?
I believe the best solution is always the most simple. Since you obviously have access to the code, do a search for the Visible property for each form element within Visual Studio and set each one to true to see how it looks. Once you make the design change then un-comment the original code.
Example:
if (someErrorCondition) {
someControl.Visible = true;
} else {
someOtherControl.Visible = true;
}
TO
/* if (someErrorCondition) {
someControl.Visible = true;
} else {
someOtherControl.Visible = true;
}*/ someControl.Visible = true;
This is not good for testing proper behavior of the form, but will let you see how each element looks for visual design purposes.
I'm writing an nginx module.
From looking at other examples I'm registering my header filter in my modules postconfiguration hook:
static ngx_int_t
mod_py_postconfig(ngx_conf_t *cf)
{
ngx_http_next_header_filter = ngx_http_top_header_filter;
ngx_http_top_header_filter = mod_py_headers_filter;
return NGX_OK;
}
But the handler is never called. I've set a breakpoint in gdb on ngx_http_top_header_filter change and it seems my module's postconfig is called first, but then runs postconfig of the ngx_http_write_filter_module which overrides ngx_http_top_header_filter w/o storing the old value:
static ngx_int_t
ngx_http_write_filter_init(ngx_conf_t *cf)
{
ngx_http_top_body_filter = ngx_http_write_filter;
return NGX_OK;
}
it seems like it is designed to be the very last on called, so how come my module's postconfig is called first?
From what I can see the order of modules is set in objs/ngx_modules.c
I was able to fix the problem by manually reordering the modules there so that my module comes after ngx_http_header_filter_module, but this feels like an ugly hack, and also makes it hard to automate build process as ./configure overwrites this file each time.
OK, so I figured it out myself. Documenting it here in case anyone else will need it.
I was adding my module to the wrong list. The nginx module is configured through a 'config' file insed module's directory. My had the following line in it:
HTTP_MODULES="$HTTP_MODULES ngx_http_my_module_name"
I searched for HTTP_MODULES usage and found nginx/auto/modules script which actually builds ngx_modules.c file. It turns out there are several possible module lists used by nginx/auto/modules. I needed to add my module to the HTTP_AUX_FILTER_MODULES list like so:
HTTP_AUX_FILTER_MODULES="$HTTP_AUX_FILTER_MODULES ngx_http_my_module_name"
This placed my module at the right place just after HTTP_HEADERS_FILTER_MODULE and fixed the problem.
I'm working in some old code which was originally designed for handling two different kinds of files. I was recently tasked with adding a new kind of file to this code. Most of my problems were solved by filling out an extensive XML file with a new entry that handled everything from what lists were named to how the file is written in plural lower case. But this ended up being insufficient, as there were maybe 50 different places in 24 different code files where I had to update hardcoded switch-statements that only branched for the original two file types.
Unfortunately there is no consistency in this; there are methods which operate half from the XML file, and half off of hardcode. Some of the files which look like they would operate off of the XML file don't, and some that I would expect that I'd need to update the hardcode don't need it. So the only way to find the majority of these is to run through testing the whole system when only part of it is operational, finding that one step to fix (when I'm lucky that error logging actually tells me what is going on), and then running the whole thing again. This wastes time testing the parts of the code which are already confirmed to work, time better spent testing the new parts I have to add on top of it all.
It's a hassle and a half, and to my luck I can expect that I will have to add yet another new kind of file in the near future.
Are there any solutions out there which can aid in this kind of endeavour? Something which I can input some parameters of current features, document what points in a whole code project actually need to be updated, and run something nice the next time I need to add a new feature to the code. It needn't even be fully automated, something that'll help me navigate straight to the specific points in everything and maybe even record what kind of parameters need to be loaded.
Doubt it matters specifically, but the code is comprised of ASP.NET pages, some ASP.NET controls, hundreds of C# code files, and a handful of additional XML files. It's all currently in a couple big Visual Studio 2008 projects.
Not exactly what you are describing, but if you can introduce a seam into the code and lay down some interfaces you can break out and mock, a suite of unit/integration tests would go a long way to helping you modify old code you may not fully understand well.
I completely agree with the comment about using Michael Feathers' book to learn how to wedge new tests into legacy code. I'd also strongly recommend Refactoring, by Martin Fowler. What it sounds like you need to do for your code is to implement the "Replace conditionals with polymorphism" refactoring.
I imagine your code today looks somewhat like this:
if (filetype == 23)
{
type23parser.parse(file);
}
else if (filetype == 69)
{
filestore = type69reader.read(file);
File newfile = convertFSto23(filestore);
type23parser.parse(newfile);
}
What you want to do is to abstract away all the "if (type == foo)" kinds of logic into strategy patterns that are created in a factory.
class FileRules : pReader(NULL), pParser(NULL)
{
private:
FileReaderRules *pReader;
FileParserRules *pParser;
public:
void read(File* inFile) {pReader->read(inFile);};
void parse(File* inFile) {pParser->parse(inFile);};
};
class FileRulesFactory
{
FileRules* GetRules(int inputFiletype, int parserType)
{
switch (inputFiletype)
{
case 23:
pReader = new ASCIIReader;
break;
case 69:
pReader = new EBCDICReader;
break;
}
switch (parserType)
... etc...
then your main line of code looks like this:
FileRules* rules = FileRulesFactory.GetRules(filetype, parsertype);
rules.read(file);
rules.parse(file);
Pull off this refactoring, and adding a new set of file types, parsers, readers, etc., becomes as simple as writing one exclusive to your new type.
Of course, go read the book. I vastly oversimplified it here, and probably got stuff wrong, but you should get the general idea of how to approach it from this. I can also recommend another book, "Head First Design Patterns", which has a great section on the Factory patterns (if you like those "Head First" kinds of books.)