When building applications, especially when using static linking and having a lot of dependences, I often feel that most of this 50-megabyte executable is just unused bloat, especially if consider only the mode I want.
Is there something that lets you run the program in various scenarious, collect data and build the program again (or tinker already compiled code) to remove the unvisited code (replacing things with abort)? If yes, how is it correctly called and where is it implemented?
I'm perfectly willing to use techniques, rather than tools.
What I've done for your problem is get a map file and just look through it.
There may well be a lot of methods for classes you doubt you need. Find out what references put them in there. Chances are it's just because somewhere something fancy was coded, like a bells-and-whistles container class, when something simple would do. Or a whole math library when all you needed was max.
After fixing that, the map file is smaller, and something else is the biggest thing in it, so you can do it all again.
And again...
This can cut out gobs of bloated binary.
Related
I am planning to create a game with the help of Flash CS3/AS3. This game will feature too many functions and lots of code. A 30-seconds demo alone I've been making here already has 5,000 lines of code, and will only get bigger and bigger as I make progress.
I'm planning on separating snippets of this code into separate as files, so I can embed them on the timeline using the include function, but before I proceed, I need to know: Is this considered a bad practice?
I mean, there will be a point in development where the code will become so huge, it might threaten the game's stability, or am I just paranoid and this is a perfectly normal way to address this issue. Pasting all the important functionality on the timeline and being done with it?
Your ActionScript code isn't going to affect your load time nearly as much as your assets. Any audio assets have to be embedded in your actionscript compile frame, which you can pick from your document properties.
If you're using library assets that are connected to AS Classes, the only place you can really practically defer loading is visual assets that are placed on stage later in the timeline, by not checking "compile on frame X" (whatever frame you selected as your compile frame). Timeline scripts are, as a rule, bad practice, so I assume that you're not using them.
include is also bad practice. I suspect it won't work like you want, but it also breaks compile-time error checking pretty hard.
I can't imagine needing 5000 lines of code for a demo that size, so you may want to revisit your design. Look for places you can reuse code (literally reuse the same code, not copy and paste it).
That's depend a lot if you are using OOP to develop or if you type your whole code in a procedural way. Having some codes drop on separate movieclip/sprite is not a bad thing, I even feel it's good! but that's true if each of them manage themself without depending. For example in a video game if you want to manage with script the animation of a specific monster, that's a great way to write the code inside his movieclip and make sure that his own script doesn't depend on others script.
I just checked out chromium's source, but I desperately need to learn how to navigate around this monster.
How would I search for parts of the code that implement behavior/features I'm interested in?
Let's say I want to see what happens after a URL is entered into the address bar. How do I find that piece of code?
Or, that I want to see what happens when, while parsing HTML, a certain tag is reached.
I have before me a huge amount of source code, and no skill of navigating around it. How do I learn that skill?
My recommendation for sort of diving in is to take a look at the source for http://code.google.com/p/chromiumembedded/.
It's sort of the condensed version of Chrome and if you look at the files it specifically uses, either ones included in its source tree, or files included therein from the Chromium repo at large. The Chromium code base is a huge amount of stuff, most of which isn't actually in the browser. There's a ton of pulled in code from third party repos which are then boiled down in the build process or Chromium's implementation is located somewhere else in the tree, there's a lot of side projects that (while interesting and an awesome resource for a wide breadth of stuff) will prevent you from achieving your goal of specifically honing in on the browser implementation and how that fits together.
CEF is great because you can see someone who's already done the process of pulling all that stuff together to build a project very specifically scoped at the browser view and nothing else. You can see which parts are primarily derived from webkit easily, you can see where the crossover comes in with Google's implementations, and you can see pretty easily how V8 gets tossed into the mix.
I do say "easily" in relative terms because we're still talking a huge amount of code overall. CEF will put you smack in the center of the requirements, but that stuff is still pulling in the massive amount of various things from the rest of the tree. Compiling it takes me about an hour on a really good computer with 12 gigs of ram and 8 cores, and the generated files take up like 6-10 gigs depending.
At the very least, there's not going to be any sort of quick jump into the shallow end to pick something here or there piecemeal. Browsers are incredibly complex pieces of engineering necessarily, because they have to subsume such a huge amount of individual pieces of functionality and then combine them into a shared context. You may find the one thing you're looking for, but you'll find that it's part of a class library that likely is composed of dozens or hundreds of files, which in turn relies on a hundred more of these libraries to handle each task, so to really take something away you'll have to commit time to taking in a lot more than any given piece of information.
Edit: oh also as your specific example.
src is root http://src.chromium.org/viewvc/chrome/trunk/src
/chrome http://src.chromium.org/viewvc/chrome/trunk/src/chrome
The "chrome" tree largely contains the direct implementations (a lot of stuff isn't in there though, most of it even, but that's the starting point). This has overlap with chromeos (chromeos is kind of chromium browser taken to a crazy extreme)
/chrome/browser http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/
Is getting you to close to where you want to be. You start to see specific references to things that you can match to the browser, like the tabs and whatnot (ignoring the giant elephant of the actual browser implementation itself which is what takes up the majority of the mindspace in all this stuff)
/chrome/browser/ui http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/
Brings you to where most of the ui code is for the browser. It can be confusing when there's crossover or when stuff migrates, like there's a "ui" in the root src directory which has some crossover.
And finally http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/omnibox/
Which has a surprisingly small amount of code in it. But this is what you find a lot. The code here is an implementation of a number of classes that are built up elsewhere. For non-webview gui component you'll find them mostly pointing back to the root "ui" and the native widgets stuff there, which is where the bulk of the actual event handling code is if I remember correctly.
You can try this... it may actually lead somewhere too :-)
http://aaronboodman-com-v1.blogspot.com/2010/10/wherein-i-help-you-get-good-job.html
Reading through the dev forums may help too...
http://groups.google.com/a/chromium.org/group/chromium-dev/topics
Also, this section has a lot of useful documents, such as style guides, etc.
http://dev.chromium.org/developers/contributing-code
Last, but not least, IRC is your friend...
http://dev.chromium.org/developers/irc
i noticed a very strange way of naming classes in G+ and gmail..
example: a-b-h-Jb a-b-Rf-dB a-Rf-dB d-s-r (see G+'s code for yourself!)
who the hell does that? impossible to keep track of what you did in future.. same for gmail.
it is a known way of doing css that i am unfamiliar with? is it OOCSS? if a googler is reading this, can you please explain? Or if you are not the one who wrote the code, then please share your thoughts or prove that i am a dumb ass and don't know about a fairly common css naming 'good practice' (can i even call it that?)
Google uses something called the Google Web Toolkit (or simply GWT) to compile Java "applications" into their Javascript/HTML/CSS counterparts. GWT was used for GMail and Google Wave and my assumption is that it was also used for G+.
The GWT "compiler" (CS purists would never call GWT a compiler but the term fits) programatically names Javascript functions, CSS classes, HTML form IDs, etc. so they are almost never something legible.
At a guess, they probably have everything written out nicely in full at some point, and then put it through some program to compress it (reduce the length of variables). This reduces readability but also reduces file size, improving load times in theory.
What are the pros and cons of using a WYSIWYG editor for web page development vs hand coding?
With the exception of just not knowing how to create something by hand coding is there any reasons to use WYSIWYG?
I handcode, but I prefer to work with a wysiwyg editor in tow, and for that reason I'm still using Dreamweaver as an editor. What I'm doing 95% of the time is handcoding inside the Source editor and viewing the results in the preview. Occasionally I'll drop into the wysiwyg editor to move blocks around directly though and when I do I find it invaluable. I never use any of Dreamweavers wizards or generated code and I clean up the html manually too.
I see nothing wrong with this approach, it strikes me as the HTML design equivalent of an IDE prompting to complete functions etc. (intellisense or whatever your IDE may call it)
I also always use a templating system of one form or another so my scripting code is totally separate from html.
The combination with Dreamweaver of the occasional wysiwyg edit (invaluable I find when laying things out or making 'macro' layout changes) and the one click preview has kept me with it despite looking at better tools - Aptana, NetBeans etc. Indeed I would dearly like to move to another system - see this question - preferably something that runs on Ubuntu and strips out the crud in Dreamweaver leaving just the wysiwyg features and possibly an intelligent Javascript editor, but I'm yet to find anything. KompoZer is starting to look promising though.
There are a variety of reasons to use a WYSIWYG editor when creating HTML.
Allows for quick prototyping
Allows designer-y people to be actively involved in front end development
Some WYSIWYG tools will set you up with a clean base to be modified (Dreamweaver's CSS layouts are actually pretty good)
I think the important thing to remember is that after you get it into approximate shape, you should dig into the code and make sure there's nothing weird going on. Nested spans, odd absolute positioning, and (lord almighty) table based layouts count as weird things. Even if you use a WYSIWYG to start with, you should always check that the code is valid and looks the way you would expect it to.
WYSIWYG can be handy if you don't know HTML or just want to whip something together extremely fast. You're not going to get clean code, though. Most WSYIWIG editors still throw out a bunch of unneeded dirty HTML instead of clean solid markup.
Anyone familiar with HTML can usually whip up something just as fast by hand in an HTML editor. And it will be clean, xhtml compliant semantic markup instead of thrown together templates with extraneous crud.
If you set up the template and css properly, you can probably be faster with hand coding than a WSYIWYG editor, as those work against you when you're trying to create properly abstracted css with degradable semantic markup.
If the design isn't terribly important and you're just throwing a website together there's nothing wrong with using a WYSIWYG. Or if you're trying to create a marginally functional mock up for a client it's a good way to get something built quickly.
I develop in ASP.net most of the time, so I'm in VS2008 most of the time; however whenever possible (which is most of the time) I still-hand code....but I do it in VS2008's source mode. When working with ASP.net, theres always somewhat bloated code which you just sort of have to accept (to a point).
However, in my free time, I also do php development, and like hell will I ever not hand-code with php. Plus, its not like VS with the drag and drop stuff.
If you want to be really good at what you do, as in Guru like good, drop the WYSIWYG stuff and start hand coding. The learning curve is steeper, but it makes you better at what you do in a meaningful way.
It comes down to maintainability and changeability. It is usually much easier to change a GUI layout in a GUI editor than by hand.
"Oh you want to move that JTable from this position to this other completely unrelated position". If you have handcoded it, it basically turns out to be a programming job (which for non-trivial layouts might actually be HARD), but if it is in a good GUI editor, it is probably just a matter of point-click-move-release.
People who handcode probably never have had to do that kind of changes :)
The advantages of using a WYSIWYG editor for web development are pretty obvious. Development is much simpler and faster even if you know how to code web since web development requires to know many different languages and can get messy when trying to get them to work together as planned. Real WYSIWYG designers should be able to solve those complexities by allowing you to visually develop on one form in one layer.
The disadvantages of this kind of development paradigms can be that it sometimes limits you, meaning that you are usually constrained within a predefined framework.
Therefore it is important to find a framework that on top of its WYSIWYG development experience is open to extension and customization. Take a look at http://www.visualwebgui.com/.
This is the same type of thing as Glade versus hand coding your Gtk code. I think that you add a level of obfuscation and things that might break when you hand edit your code. However, as Spencer said, if you need to do it and it needs to work; usualy WYSI wil work pretty well and reliably. If you're doing something that you're going to be keeping up to date and be managing for years to come; you should know every piece of code that is in that application/web page.
Really it comes down to your job function. If you're primarily a designer, WYSIWYG editors can be very handy for creating mock-ups for clients, or prototypes that can be handed to developers to code against.
If you're a developer, you'll probably prefer to hand-code.
Most WYSIWYG editors offer a code view and design view which enables you to switch back and forth pretty easily.
My suggestion is to try and learn how to hand-code your site. After years of web development, I find that hand-coding is faster for me than attempting to use a designer. Moreover, as you gain a better understanding of how HTML and CSS work together you'll find that there's very little that can't be done gracefully.
It can be frustrating to learn, but you'll find that you're better for it in the long run.
Caveat: I'm relatively new to coding as well as TextMate, so apologies if there is an obvious answer I'm missing here.
I do a lot of HTML/CSS markup, there are certain patterns that I use a lot, for example, forms, navigation menus etc. What I would like is a way to store those patterns and insert them quickly when I need them.
Is there a way to do this using TextMate?
You can do this very easily in TextMate using Snippets. Just add a new snippet in the bundle editor, and set up how you want to trigger it. You can set a key shortcut, or have it pop up when you hit Tab after a certain word/pattern.
There are many things you can do with them—in your case, it would probably be very useful to set so-called "placeholders" in your snippets, which are the parts that change every time (e.g. the names of the fields in the form). Then, as soon as you insert the snippet, you can hit Tab to move between these.
Along with the links provided above, I think you'll find this screencast useful. It gives a run through of some of the tools TextMate's HTML bundle already provides.
It's probably slightly off-topic though, but worth a look nonetheless.
As mentioned prior snippets are what you are looking for.
For reference look here:
http://manual.macromates.com/en/snippets
http://screenflicker.com/mike/code/div-snippets/