I didn't understand the responsive design analogy. I assume it's not the operating system that the developer responds to, so what is it?
The problem.
How I Develop Things and Why
31–35 of 35 posts
Re: How I Develop Things and Why
#32Earlier quoted context omitted.
MacOS (not that it was then branded as such) - 1984. Windows 1.0 - 1985. So not quite years really.
Windows 1.0 was just a fancy dosshell. Windows 3.0 should count as 1.0 in this case I think :)
Frankly I think you could make an argument even Win3 wasn't all that much to write home about....
(I confess to still mild incredulity that MacOS beat AmigaOS so thoroughly in the market, being both more expensive and substantially less powerful in both hardware and software. If Commodore had done their jobs properly, we'd be saying Steve Who?)
Re: How I Develop Things and Why
#33I've started following this rule for all of my personal projects. However, many of us find it difficult to apply this rule to the software we write on the job. Most of the projects we work on aren't for us. They are for customers with vastly different needs. When you are creating that type of product, I don't think this rule really applies.
Writing use cases and thinking about how the user is going to interact with your system is a very large part of creating correct and defect free software. Besides the obvious "will the user get it" it has a huge benefit when it comes time to design of your test suite. Consider an imperative programming language where you can have null values. A null value most often means that some piece of data is optional or not re…
Or obviate all of the potential downfalls with null by simply sticking "anonymous" in the name field.
Re: How I Develop Things and Why
#34I didn't understand the responsive design analogy. I assume it's not the operating system that the developer responds to, so what is it?
The problem.
I don’t think the analogy from web design carries over, then, does it? You’re not using the word "responsive" with the same connotation.
Re: How I Develop Things and Why
#35> Before I start writing a single line of code, I write the README and fill it with usage examples. I pretend that the module I want to build is already written and available, and I write some code with it. I write the same way. It forces you to think of how intuitive and natural your code should be. I've run into so much code that makes me wonder, "did they even consider how someone will want to use this?" Software…
This is very important, but he's making a deeper point, that the README ties it to the problem it solves. It's possible to make a beautiful, intuitive, natural solution that nobody needs (not even yourself). From the user to the code, it goes: problem -> usability -> code Although intriguingly, pure mathematicians create solutions for their own sake (without reference to a problem), and it sometimes (often?) turns ou…
reply your BTW:
modern browsers support that feature, it could be altered by css code:
resize: none | both | horizontal | vertical
many browsers use both as default