I'm fairly new to programming and have been taking courses on Lynda to learn the fundamentals. I have some knowledge of Java and HTML, but I wanted to refresh my memory so I can start learning Objective-C. The Lynda course has us working in JavaScript because of its pretty core syntax. So, in order to get a point of reference, I tried downloading some .js files integrated into HTML pages from various sources. However, this proved to be unhelpful and I am at a loss for understanding because of the way the files are formatted. It seems as if most files put one line of code after the other. I realize that because of flexible whitespace restrictions with JavaScript that this does not hinder the way the code runs, but why did the developers choose to put it all on one line like that? They obviously didn't write the code that way, as that would be extremely tedious and hard to work with, so why did it come out that way when I try to view it? Is it just something that happens when you try to download the resources of a page? Any clarification would be appreciated.
Below is a photo of a JavaScript file I tried viewing. As you can see, all the code is restricted to one single line.
Also, if anyone could offer some insight about where to go after I've finished my course if I'm looking to develop for iOS, that would be greatly appreciated. Lynda also offers an Objective-C Essentials course, as well as an iOS Development course, but I feel like it's a pretty linear path that could be expanded on greatly with some literature or other online documentation.
what you are seeing is a minified version of the javascript file. The main advantage of minification is that it reduces the amount of data that needs to be transferred (bandwidth usage).
If you wish to view the code in human readable format, you can use online tools like this
Yes as karthikr said it's minified. Which means its all there but without the line breaks. So to see it all you have to scroll right.
Or you can use http://jsbeautifier.org/ to bring back the break lines.
There are several reasons for minifying javascript. One is that it makes the code less readable (yeah, some devs don't want you to "steal" functions and see what it does easily). Another, and a big part of why, is that it reduces bandwidth. A file with long variable names and whitespaces everywhere can be multiple times bigger than a minified version - so it improves performance!
Bandwidth costs money, especially for users and especially if they're on mobile devices with a bandwidth limit.
So to solve this problem developers will minimize the file size of what ever they can.
The JavaScripts you are seeing have been minified by libraries such as Uglify or YUI compressor (list not exhaustive).
Doing this will take out unnecessary whitespace and reduce the lengths of variable and function names that are not globally exported.
Developers may also gzip the files too which will reduce the filesize even further.
Edit: grammar
Related
I am working on a project that currently uses a bunch of very big xslt files.
we use those xslt's to translate an XML from our system to an XML that the other system can read.
Our system actually receives JSONs which we actually save as XMLs just for those xslts.
We are now thinking about a way to replace the xslt with something simpler, but we have a restriction:
Those xslt's are modified by outside people (which work on the other system), so just refactoring them is not an option, since its only a temporary solution until they will become ugly again. also, we still need to find a way to let those people change the way we transform the XML - preferably without teaching them how to code.
Since our system is written in java, we would also like our solution to be supported by one of the major java frameworks.
I was thinking about a sort of rule engine with XQuery for customization, but I am not sure if that is a valid solution.
Another idea I found was to just use ruby, since many people say that it does the job better. but I fear that the teaching overhead will be too great.
I would really appreciate any ideas you might have for solving this problem.
Thanks :)
I have an issue here..and its making me really nervous.
I was working on this game, and it was going great, so I took a copy of it on my laptop to work do some work while away from my computer.
long story short, hard-drive failure + poor back ups led to me losing a very important class.
Is there a way to decompile the apk to retrieve the bit of code that was lost? It isn't overly complicated or sophisticated, its just that its impossible to re-write it without reading every. single. line. of. code. in the entire application since it initializes a LOT of classes and loads a bunch of stuff in a specific way.
With a quick google search I was able to find apktool, which decompiles it into a bunch of .smali files, which I don't think were designed for human reading.
All I need to recover is one very big method in the class. I found the smali file that contains it and I think I found the line where it starts. something like
.method public declared-synchronized load(Lcom/X/X/game/X;)I
Anyone help would be appreciated since I would have to scrap the entire game without this method.
A quick google resulted in a way to decompile apks (decompile apk to java source). However, even though it results in java code, you probably won't have any variable names (just default ones like param1) as those are unrecoverably removed when you compile the source code to byte code, also, depending on the decompiler, for/foreach loops will be while loops instead, if/else blocks might not represent your original control flow due to compiler optimization.
As a general advise: Use some sort of source control. On your own server, paid account with github doesn't matter what, but use source control. Even if you are just one person developing on a project. It helps with this situation, it helps with reverting to a previous version, it helps finding a bug you introduced. When the tools are available, use them.
I don't really love when the code in the page is written in one line, when I wasting a lot of time to try to understand something in there, really the compressed code written in a page worth it? By the principles of programming, code should be readable for others programmers who will come to maintain it too.
and by the way, HTML comments could decrease page load time? because they are visible to others.
<!-- comment goes here -->
but java comments? they is not visible to others
<%-- comment goes here --%>
I think you are confusing many concepts here.
Page compression can be done at various levels. You can employ mod_gzip and mod_deflate or similar modules on your web or web-application servers, to compress the raw bytes served by the web/application server. This often saves a lot of bandwidth and is usually not a cause of problems for web-developers, because the browser will decompress the page content before rendering it (or displaying the source back in the "View Source" context).
The "page written in one line" is not compression. The technical term is minification or obfuscation. It is typically done for JavaScript, to reduce the size of the JavaScript file being served; this can reduce the filesize drastically, with the added benefit of being difficult to parse by human-readers. Web-developers who employ JavaScript minifiers are often clever enough to have the non-minified version of the source code available, so that debugging is not an issue.
One of the former customer sites that I've worked on, demonstrated a performance increase of upto 40% when employing GZIP compression on the wire, and between 5-10% when deployed with minified JavaScript files (there were thousands of such files). But again, your mileage might vary when using these techniques.
Finally, HTML comments (<!-- comment goes here -->) do have a performance hit, as it takes more time to serve pages with comments, than pages without them. The impact on rendering might be negligible, as comments are often stripped out by the lexical analyzer. This is not true of JavaScript comments in inline script tags that are first parsed by the HTML parser. The second type of comments (<%-- comment goes here -->) is never served by the application server, as it is a JSP-style comment, and the JSP compiler usually ignores these comments, thus not generating any comments in the resulting HTML content.
HTML isn't meant to be read by others when it's being used in production. Generally the original code is going to be readable and things like HTML and JavaScript are commonly minified to decrease load time.
And yes, any comment that your browser has to download is going to increase page load time.
I don't really love when the code in the page is written in one line, when I wasting a lot of time to try to understand something in there, really the compressed code written in a page worth it?
It can be
By the principles of programming, code should be readable for others programmers who will come to maintain it too.
That is why minification is done as part of the build process. Developers working on it get sensibly formatted code.
and by the way, HTML comments could decrease page load time? but java comments? they is not visible to others
If it is delivered to the client, then it takes up some bandwidth. That may or may not be a significant amount of bandwidth depending on the context.
Some do it intentionally to discourage examination of their code, although with some effort it can be well formatted and be readable again. This is a bit like code obfuscation seen in Java.
I am looking for a Java library that let's you write large PDFs sequentially with a minimum amount of memory. Most of the libraries I had a look at has to build up the document in memory first before you can actually write it.
The problem I have to deal with are OutOfMemoryErrors. It would be great if I could flush the writer programmatically whenever needed e.g. for each page.
Does anyone have any recommendations? I need something with a license along the lines of the LGPL (so not the GPL or the Affero GPL that iText uses).
You can do that with iText. It supports writing to OutputStreams.
The free version of Docmosis has a fairly open license so it might suit you. It uses a template-approach which is different from building from code. Docmosis processes all documents in a stream-based fashion since it's intended for singificant parallel use and for large documents. It also allows you to offload the most CPU intensive part processing to another server. Hope that helps.
I actually, had same issue as you do, a friend help me out, but he did in C# and using an api called GhostScriptSharp, you should check for it.
I can't give you a copy of the code, since its copyrighted, but i'm sure it would help you out, since the tool i think is builded on Java.
jPod can swap indirect objects and supports incremental writing.
This is still not optimal as you need an "increment" on each flush, but better than nothing...
EDIT
Öhhh - this is one of the famous examples of self describing code :-) Your're right, theres not much of a tutorial or that - but the Javadoc is quite good.
jPod writes incremental by default. See "CosDocument.setWriteModeHint" to set to full mode.
The example "CreateDoc" and "AppendPage" are simple examples of how to add pages. You may do the same and call "save" every 10 or 100 pages. This should "soften" all references to pages in memory and if not held by some other references of yours, the can be garbage collected.
THere's still the question how you fill the pages? THere are examples dealing with content streams, too (DrawText,..). BUT jPod is not like iText, jasper or whatever. There's only PDF model abstractions. You have no "Layouter" or "Renderer" that creates page content from text, html or something like that. How do you do this?
I'm working on a school project in which we would like to analyze the content of webpages. We don't, however, want to deal with things like Nav bars and comments. If we were looking at a specific website we could make a parser to filter that sort of extraneous stuff out specifically for that site, but we are hoping work on arbitrary sites that we may not have ever encountered before.
I feel like it's a bit much to hope for, so I won't be surprised if nothing like this exists already, but does anyone know of a tool that can do that sort of content isolation on arbitrary websites? I've had a bit of luck diffing pages with others from the same site, but it's imperfect and leaves comments and such.
I am working in Java, but would welcome anything open source in any language that I can use for ideas.
I'm a little late to this one (especially for a school project), but if anyone finds this at some future point, the following may be helpful.
I stumbled across a Java library to do exactly this. Performance, in my simple tests, is similar to Readability.
http://code.google.com/p/boilerpipe/
You could try an unofficial API of arc90's Readability.
Basically what Readability does is extract content on a webpage and presents it to you as a nicely formatted article. Nav bars, comments, and all the other stuff that surrounds content on a webpage is gone.
im also a bit late to this conversation but ...
the Java Boilerpipe extractors are probably what you want (ArticleSentencesExtractor probably), although there is at least 1 port of the arc90 readability to java on github.
If you want to build a poor mans boilerpipe you might try diff'ing 2 pages from the same site (assuming they are using the same template you will likely get an interesting result)
The main difference between boilerpipe, readability and a diff based hack is that boilerpipe will strip out all html but preserve some structure
I doubt that anything exists that would do what you want. Without some sort of semantic markup it is next to impossible to distinguish "real" content from the other stuff. This is a task that requires real intelligence.
There are of course good tools for parsing HTML of varying degrees of correctness, and it is often possible to cobble together some pattern-based solution for dealing with pages on a particular site ... assuming that there are common structures / patterns to be elicited.