Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've downloaded the source code of my favourite program.
At school they taught us that the entry point is the main.c(pp) and then follow the headers, but I realise that is not always the case. In some cases there isn't a main or It deep buried somewhere where I can find it.
And the documentation in most cases describes only how to compile, what deps you need and etc.
Bottom line, you've downloaded the code, untar'ed it.. now what?
I don't have any particular example to ask (help) for, so if you have any example to help me it's welcome
Reading code is often more cumbersome than writing code. This inquiry does not have a single answer and you should explore multiple opinions and see which works best for you. One practice you shouldn't engage in is reading the code start to finish. This will lead to eye bleeding and mind-numbing frustration. So don't approach it like a book, since reading it like one, cover to cover, is very inefficient. Reading is not learning. Applying what you read is learning. One key point to remember is don't get discouraged. You will be hard pressed to find a programmer that can quickly pick up on a foreign, large base of code quickly.
The best 'book speed readers' skim through something they are about to read a form an outline in their head. They take mental notes of logical sections and paint a thin picture about what to expect. When your brain has seen something before, it is more likely to be engaged with the material. I would skim the header files as a way to form this outline. If there are no header files, then try to skim quickly though class interfaces and take note of which are connected and what is their general purpose.
Make a second pass through the sections of code that interested you. Try to identify a subsystem of the code and make a second, more detailed pass through it. I personally would look for connected components for identifying the subsystems (look at imports). Jot down some of the data structures used and associated algorithms and design patterns. Make associations between them and try to understand why they were used.
Lastly, don't be content with just reading the code. Since you are looking at open source, challenge yourself to add a feature. Take one of the subsystems you were intrigued with and add on to it. If this still intimidates you, take the last bullet a step further. Make a quick flow chart detailing the flow of the code. Bust out your favorite IDE and leverage breakpoints around areas you don't understand the flow. Try to put yourself in the mind of the designer and think why he made certain decisions as your stepping through the breakpoints. Bottom line: It is easy read something and think you understand it. But, doing is where the real learning takes place. You will find yourself asking more questions and researching more into the code when adding a new feature. Having this direction is all it takes sometimes.
If the source code leverages an OOP solution, I would strongly recommend studying a Design Patterns book. I was going to include Design Patterns as a bullet, but I didn't know if the source code you are viewing uses an OOP approach.
Hope this helps! This was the approach I undertook when learning to code a couple years ago.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm creating a board game in JavaScript (just to help learn the language) and I was wondering whether to use tables or divs (and CSS) for the board.
From what I understand, with tables the browser reads through the code twice. Once for the structure/layout and then again for the data.
I realise the page will only be loaded once so it won't make too much of a difference, but I was just wondering whether a game board would be an acceptable use of tables, since it's usually reserved for tabular data, or should tables be shunned altogether, even though divs require more code?
Using a <table> element to describe a game board is perfectly acceptable in my book, for example a chess or checkers board, Game of Life, etc, as (to an extent) the game state can be both represented-as and interpreted-as tabular data.
Use table-layout: fixed to have a table that uses a more efficient layout algorithm that's a lot faster and predicable, however can lead to a poor layout unless you've manually optimised it (usually by setting manual column widths).
The algorithms used are described here: http://www.w3.org/TR/CSS21/tables.html#width-layout
I think this question mainly depends on what you plan on doing with this board game: Is it for ONLY practicing JS (meaning no one else will see it) or will it be later used for other people to utilize it?
In my opinion, we all need to start somewhere, so it is acceptable to use a table in your creation of the board game if you are looking to experiment. In fact, you shouldn't need to worry about optimization if you are only using this to enhance knowledge and for your own personal use.
However, in another offset opinion.. I would suggest you begin to look at the idea of using divs/uls/lis to create a table, as this practice is really invaluable and it is honestly a good idea to begin grasping this idea early rather than later. It will also give you the feel for how CSS can represent multiple things in various ways and how you can also manipulate CSS to really do whatever you want with it.
If you are planning to have this game made public so other people can play, you will want to look into what will optimize the speed or performance of your website. This is where the links that were provided could be of use. In all reality, everybody has their own opinion on this matter and it will be a constant fight until there is solidified evidence on this matter. I would imagine by the time they decide which layout is better, CSS will already be upgrading and optimizing to its fullest capabilities.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Hey everyone I just bought the master cs5 suite mostly for design purposes, and now I have a lot of peoPle telling me I should start using DW instead of hand coding my HTML/CSS because it will speed up my production and it's what all design shops use and is an industry standard . I was curious if this is accurate and how much would it really speed things up?
I (personally) disagree. I use DW in CS5 for code editing view only (it has the best markup/code highlighting I've found); the generated markup is not great, so I don't use it, nor am I highly trained in the workflow it entails. A lot of designers will not understand hand coding markup, but that's usually because they don't understand how to or don't care to do so because it's not what they get paid to do.
However, if you're working on (a) lower level, you have a better understanding of your markup/styles/code. It may take slightly/significantly more effort (depending on your abilities hand coding), but I personally think it's worth the effort in many cases. However, I am not a piece worker nor am I paid on deadlines.
There are other reasons I use DW (WebDAV support, searching capabilities), but I will likely never use it to author my markup. Also note I don't pay for it.
Used unwisely it won't speed it up at all. You'll spend more time pulling out DW's extraneous code. Use parts of DW that will make you faster like snippets (for storing snippets of code you use frequently) and find and replace (using f&r with regex is a very useful skill). I use it to cram in table markup quickly (for data tables). Dragging files over for internal links is quite nice and the keyboard shortcuts help (you can create custom ones).
That said, I like the product at work. Check in and check out has been very helpful there with multiple coders/designers.
So, there are plenty of parts in DW that will speed up your hand coding. Root them out.
Dreamweaver CS5.5 made a lot of improvements over previous versions. As a designer you may appreciate Live Preview and the design integration's. As a coding IDE, it's still considered sub-standard and many developers choose to go another route. I use PHPdesinger 7 for ~$70, its got in-line xdebug integration and pretty good intellisense for PHP, CI, and jQuery. I use DW5.5 and PHPdesigner and I find it's far less bloated then Dreamweaver for what I use it for, coding with PHP/Jquery and web API's. I also feel that it's closer to how I worked before using advanced IDE's like this, coding on my Macbook with Coda. But if your designing web pages you may like Dreamweaver better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to get in the habit of designing the interfaces to my websites at the very beginning before I do any actual coding. I've read "Getting Real" by 37 signals and they recommend doing the interface first, before any actual code is produced.
What exactly is meant by that? Does that mean use pure HTML and CSS to design the site and add php, js logic to page afterwards, or is it okay to sprinkle in the php, js from the beginning?
What if your using a framework, should I set up empty controllers that simply call the views, or should the early stages be solely html, css?
Also, what do you guys think about design first vs later?
EDIT I'm talking about AFTER I have sketched everything with pen and paper.. I'm taslking solely about the html mockups. And I'm not too sure about using extra tools that I would need to learn to do this
I think that the majority of the benefit of designing the interface first has been achieved after you are done your paper sketches. Basically, you are just ensuring that you have a design in your head and that your coding process is somewhat end-user driven. You are also trying not to waste time on needless documentation.
Getting the HTML in place (or the skeletons of the Views in an MVC app) makes some sense and this is the main thrust of what 37signals says. I would certainly not do anything beyond this that is just going to be thrown away.
I think if you have a proper design, it is immaterial if you next move on to writing the back-end code after the HTML or if you do the CSS and JavaScript. The CSS and the code should not even need to be aware of each other.
Do whatever gets you excited and motivated. Do whatever gets you thinking more deeply about how the app will actually work so you can catch any flaws in your original thinking. I like to code before CSS but that is just me. You might find it important to get the CSS further along before the app takes shape in your head.
Joel Spolsky likes Balsamiq as a mocking tool. I think that 37signals uses Draft (an iPhone app). I use a Sharpie. The key is not getting too detailed though.
Opinions vary, but I believe that JavaScript should come last. I believe most sites should be designed so that they work 100% without JavaScript and then have JavaScript added for polish.
Learn more about Unobtrusive JavaScript
So (for me):
Quick and dirty sketches of views
Get some HTML in place
Maybe some basic CSS for layout (or more if I need to impress somebody early)
Write the core logic
Add support for web services and AJAx calls
Pretty it all up with snazzy CSS
Write some JavaScript to add the sizzle
Let me ask you this. Do you paint a car before or after you have made the working parts? Maybe you have chosen which paint but ultimately it cannot go on until the car is finished. Maybe you don't agree with this analogy but I think coding will bring out issues that cannot be understood before a site is designed. Code first, design second.
Get a pad of paper. Each page represents one page of your site.
Sketch the interface. What controls go on each page? What controls are the same on each page? What forms are there and on which pages? What happens when user clicks on item x? Item y?
This will help you solidify your plan of both the content and behaviour of your site.
If you just start blindly coding you will end up with burnt spaghetti.
The user interface is what the users of the website will see. Before coding you probably start with some very basic sketches of the site that are not code, to identify page navigation, general placement of content and interaction with the site.
But the earlier you can show and discuss a working UI, the easier it is for the users/client to get an idea of the final product. So quickly move to the HTML, CSS, JavaScript and things like images, to identify:
The data presented on the page (HTML)
The representation of the data (CSS)
The interaction with the data (JavaScript)
Doing so helps to gradually develop an actual working UI that you can discuss with the client. This keeps them involved from early in the project. It forces them to think about the site, and make decisions about content, look and interaction.
Getting such feedback early in the project reduces the risk of building a product that needs to be changed later on. And making changes early in the project is easier/cheaper, then later in the project.
While the UI is being developed you can already start looking into data structures, software components and integrations with other systems to drive the site. But that's not what users/clients are interested in, they want to see and use the product.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm supposed to do a presentation for my co-workers on a web framework I evaluated. These people are developers and hate long and boring PowerPoint stuff, so I got lots of little code snippets. I also put together a small sample application. My question is, how do I present the code so people can follow?
Some things I thought of:
Put the code on PowerPoint slides, looks pretty bad and unless it's an image I can't get syntax highlighting to work. Having my code in images is a pain and doesn't scale well to different resolutions.
I played around with the S5 XHTML presentation format and integrated a JavaScript syntax highlighter. It's a bit clunky but workable (I'll get some grief for ignoring the company's CI for presentations since I wouldn't use their templates. Don't even ask...)
I could put together a script (notes) and "live-code" in front of my audience. I don't like this so much because it keeps me so busy that it's hard for me to give a good explanation while I write. And there's also a high chance of me causing errors and make them wait.
A screencast? But then I wouldn't have to be there... Maybe narrate it?
So what would you do?
I could put together a script and
"live-code" in front of my audience. I
don't like this so much because it
keeps me so busy that it's hard for me
to give a good explanation while I
write. And there's also a high chance
of me causing errors and make them
wait.
I like this option, if you can get your demo streamlined to the point of not holding up the audience. You can do what TV cooks do when the recipe takes more time than they have; start the coding, then jump ahead to one that's 90% or 100% done.
If you have a colleague you can get up to speed, you can have them do the coding while you talk and point out what they're doing.
You can use your IDE, which will give the syntax highlighting and show your audience how to compile, deploy, test, etc. I would recommend using an oversized font though, just for the session, so that everyone can see.
Does your IDE allow opening/closing regions or code segments? In Visual Studio you can create code regions that you can expand or collapse. If your IDE has the ability to do this you could create your code samples as regions and then open/close them as you go through your presentation. You could switch back and forth between your presentation and code samples in the IDE, but wouldn't have to code on the fly. Using open/close allows you to hide the code you're not referencing to keep things less cluttered.
I actually saw this done at Agile 2008 and it seemed to work pretty well.
You can only fit so much information on a PowerPoint slide but that's actually a good thing: people can only look at a certain amount of information and get something meaningful from it.
So if you can't fit it on a PowerPoint slide, you need to rethink your approach.
Code snippets are good. They don't need to be highlighted. Just put them in Courier New (or some other fixed width font) and it'll come across as code. Code snippets don't have to be complete either. Just boil them down to the essential concepts (using comments or ellipses to indicate missing code).
Programmers being programmers, they'll probably ask questions when it gets to the technical, which is good.
Also, if the programmers are familiar with something similar try and relate all the concepts back to what they know. It makes it easier to grasp. Like if you're explaining Spring MVC and they know Struts, explain the Struts equivalents. It can be useful to put that sort of thing in table form (even as a handout).
That's what I did for exactly that (a Spring MVC primer for Struts programmers).
If you want your audience to see a lot of code snippets, especially lengthy ones, you could print them out as handouts or provide them as notes in PDF or text files (people can follow along on their laptops).
Actual presentation slides should contain the smallest amount of text (including code) necessary to convey your ideas. If there's a lot to read from a distance, your audience will get tired after awhile and might have trouble following along. Let people read the full code sections on their own laptops or handouts, while calling attention to just the critical parts in your presentation slides or script.
If they don't like Powerpoint, don't use use it. We use Camtasia screen recording to record 'live' demos for presentation to customers (live in quotes since it doesn't have the disadvantage of crashing halfway through your presentation :-). They always prefer to see it in action rather than what they think is fudged functionality.
It's pause-able like your Powerpoint slides and has the advantage of syntax coloring since you just record bringing your up in your favorite editor. It's also dynamic which is much better than Powerpoint (although I've seen some people do crude animation with multiple Powerpoint slides, always funny to watch in action).
This basically maps to your screencast idea but, if you want a reason to be there, do a large number of small screencasts to show interspersed between your real presentation, narrating (in person, not on the screencast) if necessary.
Personally, I'd prefer to send a fully narrated Camtasia off to the target audience but that's because I'm not totally over my early-career phobia of public speaking :-).
In a pinch, you could do a real live demo since your audience (is videance the equivalent for video presentations?) are programmers and will understand any problems you have.
I had this done to me, and thought that it was the best possible solution:
Get another person to help you out. While you are talking about the code, let the helper type the code. This way everyone in the room will be looking at the code, while listening to you explain it.
This of course involves finding someone who can help out, and understand the code just as well as you do. But the results can be great.
If you could do it all in a screencast and you wouldn't have to be there, then do a screencast and don't be there. Nobody complains when a meeting gets canceled. Just distribute the video, maybe with an accompanying report with notes or links so people can read more about the tools you're demonstrating.
And you'll get more credit later as your co-workers and managers talk to other people: "Hey, did you see the presentation Bibac did? No? You should; I'll send you the address after lunch."
If you're demonstrating code in the presentation, then also consider having the finished project available so people can try it for themselves.
When I give presentations involving Visual Studio I put code snippets on the general tab of the toolbox. During the presentation I drop/drag these code snippets into a code file, markup page, etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm pretty sure most of us are familiar with the concept of a project's requirements changing after it starts, this becomes more and more of an issue the less the client knows about how things work and the closer you work with them.
How then can I design a system (specifically a website but general advice will probably be best here) so that smallish changes can be made, are there any programming strategies that deal with this issue?
All the normal oo principles apply here, reduce coupling, increase cohesion, don't repeat yourself etc. This will make sure you have a flexible and extendible code base.
Apart from that don't try to preempt change. Apply YAGNI (You aint gonna need it) everywhere. Only build stuff you know your users need. Dont build stuff you think you're going to need. You're more likely to guess wrong and then you've got a bunch of code that's probably only in the way.
I think the biggest thing is to make sure you have a comprehensive test suite. That way you can make changes confidently when needed and know when it breaks.
Having no experience with PHP, take this with a pinch of salt.
But it's all about knowing change will come. So when you are coding and start wanting to hack things to get them done, stop and think "what if I need to change this again?".
Now, I know php is a scripting language, but you must be able to library off code right? Thats the best thing to do, keep the UI (the web page) as LIGHT as possible, for the most part 1 or two method calls.
If you have fancy rendering logic, library it. Create a nice look that may be common? Look at what might change (colour scheme etc.), library it. You're already putting all your core code into libraries though right? ;)
If you always work on building your library, all you need to then do when the change request comes in is "find the right book for it".. Whats cool about what we do is that if the book is well written, you can easily add annotations to it ;)
This is basically what I am doing at work at the moment, my "project" is to build the platform that future apps will be working on, so this is really my main focus. :)
Update
Mendelt made a good point on applying YAGNI, with all of the above, don't just write stuff to library it but if you think for a second that the sexy little table you just created (because a client wanted it) might be used again, then it's time to think about making it more usable. Some obscure function for a one-off client should be done ad-hoc.
Well, I'd try to tackle this problem from the other side:
More communication with the customer/user.
I have been there myself, programming things that were not wanted or not properly communicated and having to redo lots of code. It would have been prevented with more communication or rather: with more of the right communication.
Aside from that:
Allow Users to change the color and ask them now and then, where to place a button and the probability, they will be satisfied with this "great level of control" is quite good. And then they won't want you to redo real features. Yes, I am sarcastic about this.
I suggest using a tried and tested framework for your language of choice. Most good frameworks will have been designed to accommodate a multitude of scenarios.
First, you should identify the aspects that will have a high change probability. These aspects should be 'abstracted out'. A classic example is the style of your website (i.e. through css). But you could even so define a 'presenter' class that lays out the specific elements of a web page.
The hard thing is making a correct estimate of the change probability. But that's up to you :)
This is where frameworks come into play.
If all the baseline, background, business-as-usual is in the framework, then your application is the extensions, special-cases and add-ons.
The framework is already designed and built for change. Your stuff is the change that the frame was designed to accept.
When change occurs, you will respond to change with some combination of modifying the framework configuration and rewriting your stuff that plugs into the framework. You cope with change by not focusing on the default, background stuff. Delegate that to someone else -- the framework authors.