|
FORTRAN question:code:Edit: Nevermind. integer token_count needs to be declared in read_file(). Twiggy Johnson fucked around with this message at 20:06 on Dec 8, 2011 |
#
?
Dec 8, 2011 18:47
|
|
|
|
| # ? May 15, 2024 01:26 |
|
|
edit: I'm gonna move this to the osx thread because this is related to a certain language. I'll read the OP next time sorry :/ edit 2: oh thanks! I'm gonna try that man! Dr. Notadoctor fucked around with this message at 22:36 on Dec 8, 2011 |
|
#
?
Dec 8, 2011 22:33
|
|
|
Dr. Notadoctor posted:Hey I'm a complete novice when it comes to programming, so this is probably really easy. I'm trying to root my Droid X which got unrooted after I upgraded to gingerbread a little while ago. After some google searches I keep coming up with a method which looks like this: cd /path/to/the/file/ sh run_to_root_your_droid3.sh Jonnty fucked around with this message at 23:25 on Dec 8, 2011 |
|
#
?
Dec 8, 2011 22:35
|
|
|
Jonnty posted:cd /path/to/run_to_root_your_droid3.sh ok, so here's what I'm getting now: code:
|
|
#
?
Dec 8, 2011 22:42
|
|
|
I don't know OSX, but I'm going to go out on a limb here and say you need to extract the .sh file from the .zip file first.
|
|
#
?
Dec 8, 2011 22:48
|
|
|
Jethro posted:I don't know OSX, but I'm going to go out on a limb here and say you need to extract the .sh file from the .zip file first. I did. The folder name ends in .zip edit: changed the folder's name to remove the .zip and it worked. I'm a loving idiot. Thanks guys! Dr. Notadoctor fucked around with this message at 22:54 on Dec 8, 2011 |
|
#
?
Dec 8, 2011 22:49
|
|
|
This is a Matlab question, but it doesn't matter what code you want to go with. I just need some advice on how to program this: So I'm doing some Finite Element Analysis (which is fancy talk for bullshit). Anyway, we have an equation like this: [K]{U} = {P} + {F} (the [] implies matrix and {} implies a vertical vector) I want to solve for the U matrix, which should be as easy as telling the computer to do this: {U} = ([K]^1) * ({P} + {F}) However, I want this to be solved with certain U values as zero. This seems silly, but I can't solve for the matrix and simultaneously say, "HEY YOU! YOU'RE ZERO, NOW AND FOREVER!" to parts of the U vector. Does anyone have advice? EDIT: Actually, I solved it. Solution soon to follow (and by that, I mean tomorrow, because it's 2am). Spaghett fucked around with this message at 09:10 on Dec 11, 2011 |
|
#
?
Dec 11, 2011 06:53
|
|
|
Does anyone have strong opinions of DCI ? http://heim.ifi.uio.no/~trygver/themes/babyide/baby-documents.html It seems to be 'hey this is how we use traits' - I am wondering if there is something more to this edit: well it seems to advocating the use of traits as extension classes to extend simple containers with features, using the scope of the extensions to limit the interactions. tef fucked around with this message at 19:17 on Dec 11, 2011 |
|
#
?
Dec 11, 2011 19:12
|
|
|
While reading the wikipedia page for DCI I noticed they use the example of a bank account, like so many other explanations of stuff that uses OOP. It got me thinking: what does the actual code for a bank account look like? Clearly most of it's going to be incredibly convoluted, in some awful language like COBOL and (most importantly) completely confidential, but is there any legacy stuff that a bank might have actually used kicking around in the open somewhere?
|
|
#
?
Dec 11, 2011 19:41
|
|
|
And as a follow up, where can I find an actual implementation of a Cat that inherits from an Animal?
|
|
#
?
Dec 11, 2011 21:02
|
|
|
moved to webdesign thread? i guess?
|
|
#
?
Dec 13, 2011 03:15
|
|
|
pokeyman posted:And as a follow up, where can I find an actual implementation of a Cat that inherits from an Animal? This is extremely relevant: Goodbye, lovely Car extends Vehicle object-orientation tutorial. God, I love Kragen
|
|
#
?
Dec 13, 2011 03:32
|
|
|
I want to write a very simple web application that calculates a student's average, and I want to provide a link to it so my classmates can calculate their average going into the final exam. Now, I have zero web programming experience and I don't want to spend a ton of time on setting things up. Is there a site or service out there that will allow me to spend 30 seconds writing the application and allow people to access it to calculate their average? It will literally only be one or two lines of code. *And yes, I realize that my classmates should fully be able to do the math and calculate their own averages but a lot of them seem to have trouble with it.
|
|
#
?
Dec 13, 2011 05:08
|
|
|
Hughmoris posted:I want to write a very simple web application that calculates a student's average, and I want to provide a link to it so my classmates can calculate their average going into the final exam. The very basic solution, and the one I would recommend, is to write it entirely client-side with JavaScript and jQuery. Since you don't need any server-side programming stuff, you can host it on a cheap, free webspace. You won't get out of learning programming, though, and it may take you a few days to get it working if you don't have any programming experience at all. Good luck!
|
|
#
?
Dec 13, 2011 05:14
|
|
|
Suspicious Dish posted:The very basic solution, and the one I would recommend, is to write it entirely client-side with JavaScript and jQuery. Since you don't need any server-side programming stuff, you can host it on a cheap, free webspace. You won't get out of learning programming, though, and it may take you a few days to get it working if you don't have any programming experience at all. Good luck! Thanks for taking the time to reply. The exam is tomorrow so I guess its pointless at this time. Color me surprised that there isn't a site out there that caters to something like this, figured it would be more common. I guess its more complicated than I thought.
|
|
#
?
Dec 13, 2011 05:16
|
|
|
Make a google docs spreadsheet with a formula in it. Have it so other students just put their grades into labeled cells.
|
|
#
?
Dec 13, 2011 07:07
|
|
|
JawnV6 posted:Make a google docs spreadsheet with a formula in it. Have it so other students just put their grades into labeled cells. You can make it even more idiot-proof by creating a form to populate the spreadsheet.
|
|
#
?
Dec 13, 2011 10:25
|
|
|
Suspicious Dish posted:This is extremely relevant: Goodbye, lovely Car extends Vehicle object-orientation tutorial. Excellent, thanks for that.
|
|
#
?
Dec 13, 2011 18:17
|
|
|
JawnV6 posted:Make a google docs spreadsheet with a formula in it. Have it so other students just put their grades into labeled cells. Time has passed but this is a great idea I'll keep in mind for the future, thanks.
|
|
#
?
Dec 14, 2011 05:20
|
|
|
Apologies if this question has been asked and answered before, but I'm a beginner Java developer (specifically developing for Android phones). I'm coming in to it from PHP, so that might shed some light on my background. I've done some OOP before in PHP so getting a handle on classes, inheritance, etc. while working in Java hasn't been very hard. I feel I understand the concepts well. But, I'm curious about one thing and I suppose this is more of a design question: Why do I want to use an abstract class versus an interface? Now, I know the definitions of what the two types are. But, I guess I don't know why you would bother with an interface? Abstract classes make sense to me. If I'm writing a set of connectors that might access different web services, I'd probably write an abstract class that has some core methods all inheriting classes will use. So I might define a method in the abstract class to establish a DB connection or insert a row. Then, I could write a WeatherService class that extends my base class. Then someone could just instantiate WeatherService and it could connect to the DB using the method inherited from the abstract class. And bonus, I don't have to duplicate code to define the DB connect method in the WeatherService class (and any other service class). Okay, now, from I'm reading on interfaces, they're simply a skeleton or template of what you want your classes to do. Using the web service example, I could have WeatherService implement interface 'WebServicesBase'. Inside WebServices Base, I could define the connectToDB method. Great, so the WeatherService class has inherited this unimplemented method connectToDB. But, I still need to type out the method signature again for connectToDB AND now I need to write the code for it. I'll also have to do this for any other web service class I need to write. So, why bother with the interface when all it provides are empty methods? especially if I need to fill out with code for every single class I write that implements the interface? Why not just copy-and-paste the connectToDB method into all the web service classes and skip the interface all together? The only helpful use of the interface I'm coming up with is if you're working with a team of developers. If you're all writing web service classes, I could see using an interface so that all developers are forced to use the same naming conventions, have the same data input and return types, etc. Basically, it seems to me like the interface is only really useful for keeping your team on the same page and locked into a design pattern. FWIW, I'm the sole developer of this app. I won't have to work with other devs on this one. That way, you don't have developer A calling the DB connection function FUNNYRabits, developer B calling it ConnectToDBandSHIT, etc. I'd really like to know the true reasons and efficient ways of using abstract classes versus interfaces. In the app I'm making, it needs to talk to several PHP based services hosted by a server. My design so far has been to write a base, abstract class that hosts constants like the URL to the service, the PHP script name, arguments passed in the URL, and the error codes returned. I also plan to migrate to it the functions to connect to the server and pull data down. I'll then extend this abstract class by writing a concrete class for each service. So a class to log a user in (ex: LogInUserService) will gather the user's login and password and store those in variables local to class LogInUserService. Then the class can call the inherited methods to set up a URL, connect to the server, and pull down data. TL;DR Learn me on why to use an interface in OOP. Every tutorial I find sucks. 
|
|
#
?
Dec 14, 2011 19:47
|
|
|
Dolemite posted:But, I'm curious about one thing and I suppose this is more of a design question: Why do I want to use an abstract class versus an interface? Now, I know the definitions of what the two types are. But, I guess I don't know why you would bother with an interface? For starters, you can only extend one abstract class but can implement any number of interfaces, which allows you more flexibility with objects. Using your example, what if you want your WeatherService to be Serializable as well as a WebServicesBase, but you don't want all WebServicesBase to be Serializable? Using an example from the standard library, the Integer class extends Number but implements both Serializable and Comparable. This interface behavior is very useful because it allows things like Collections.sort(), formally: code:
|
|
#
?
Dec 14, 2011 20:22
|
|
|
Dolemite posted:Interface vs abstract base class questions http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=inheritance+vs+composition For the record, I personally avoid inheritance whenever reasonably possibly and always compose behaviors. Also, as baquerd said above me, you can implement multiple interfaces in many languages, but don't let that be the motivating factor--generally if you're implementing multiple interfaces on a single class your class is doing too much.
|
|
#
?
Dec 14, 2011 20:37
|
|
|
Dolemite posted:Interfaces Interfaces are a way for libraries written by different people to signal what methods they expect/implement. Java has an interface called Comparable. If you implement Comparable, this is your way of telling the standard library that your class has a method with the signature public int compareTo(Object o). Java does not know how this method works, all it cares about is that it exists, and that this means lists that contain objects of your class can be sorted. If you had a compareTo method, but did not implement the Comparable interface, Java would have no way of knowing that your objects could be compared without using reflection.
|
|
#
?
Dec 14, 2011 21:45
|
|
|
Jethro posted:Interfaces are a way for libraries written by different people to signal what methods they expect/implement.
|
|
#
?
Dec 14, 2011 22:26
|
|
|
I've always had interfaces and abstract classes explained as effectively being opposites. An abstract class is a starting point to build on, with the purpose of the class you build being generally specified by its abstract parent. An interface is effectively a 'bolt-on' which provides a guarantee (or contract) to other pieces of code that your class behaves in a certain way. Or something. Its one of those things I 'get' in my head but find it hard to explain elegantly.
|
|
#
?
Dec 14, 2011 23:57
|
|
|
rolleyes posted:An interface is effectively a 'bolt-on' which provides a guarantee (or contract) to other pieces of code that your class behaves in a certain way. Every single class that has a non private method is providing a contract that any other piece of code can depend on; this isn't unique to interfaces. The real benefit of using an interface over an abstract class is that it doesn't bring with it all the baggage that extending an abstract class would impose on your class. I'm going to share a story to help elaborate. I created an application would download and parse news stories from the web. Originally I only used RSS feeds to get the stories, and so I created a regular class called RssParser. It did everything necessary, like parsing out all the common fields in the RSS format. But as I started adding more feeds I realized that some of them didn't follow the standard that well or omitted certain fields like the publication date. So I started having to create subclasses of RssParser that dealt with each one of those quirks. After a few different news feeds it became apparent that no feed could be simply parsed by the base class RssParser and so conceptually it made no sense for the abstract class to be regular class that could be instatiated, so I made it abstract. It provided sane defaults so that each subclass only had to override certain methods like getPublicationDate, but the bulk of the logic was still in RssParser. Eventually I ran into a feed that wasn't RSS. It was just a plain old HTML page that I had to parse using jsoup. Here is where the interface finally comes in handy. If I had extended from the RssParser my new class would have had to deal with its implementation details. Instead what I did was create an interface called NewsStoryParser that just had one method, parse() which returned a list of NewsStory objects. I refactored all my code that used the RssParser to instead use the new interface. I then made the abstract class RssParser implement the NewsStoryParser interface. My new class also implemented the interface as well and now all of my existing code could use it and it didn't have any of the baggage that RssParser would impose on me. Here's a very important observation: I had to change every "client" of my RssParser to use the new interface. I could do this without problem because I controlled all the code that made use of it, but if I had ever released this as a library I would be in trouble. If I had used the interface from the beginning I wouldn't have had to change anything and my clients would be unaware that they received a news story from an HTML page and not an RSS feed. In this case I can say it was because of a lack of foresight and laziness. When I started this project I didn't want to create an interface when I new that I was only going to be dealing with RSS feeds for a while. This is how I think software typically grows, and it's OK. It's hard to make that trade off between extensibility (which classes deserve to be interfaces) and class bloat (having tons of interfaces with only 1 implementation) at the start of a project. So just do the best you can up front and deal with the refacrorings as they come along.
|
|
#
?
Dec 15, 2011 00:57
|
|
|
Are there any free lightweight .fla file viewers? I have some code that someone wrote in flash that I want to see.
|
|
#
?
Dec 15, 2011 06:25
|
|
|
Orzo posted:Are there any free lightweight .fla file viewers? I have some code that someone wrote in flash that I want to see. The FLA file format is based on the MS OLE file formats. I've used libforensics to dig through FLA files in the past -- the script data will be spread across a number of files in the UTF16 format, so make sure you convert the files to a sane format.
|
|
#
?
Dec 15, 2011 16:09
|
|
|
Thanks, I actually found a solution later last night and forgot to edit my post or reply. I actually had an fla and a swf, and http://www.showmycode.com/ worked for me when I uploaded the swf.
|
|
#
?
Dec 15, 2011 16:32
|
|
|
Thanks everyone for your responses. They're helping me grasp the point of the interface. I forgot to mention in my research that I did learn about Java letting you implement multiple interfaces but only allowing you to extend one class. Also, the source of my original tl;dr was after Googling 'Abstract vs. Interface' So maybe my understanding is still off. But, from everyone's examples, I can assume an interface works like this: 1.) We write an interface Foo with a method like code:code:code:One area where I'm beginning to see the similarity to this is how development for Android works. When developing with Eclipse and I want to instantiate something, the code hints force me to implement a certain interface. Since Android works on a system of call backs for some items, is the reasoning behind requiring the interface such that if the Android system calls a certain inherited method in my class, it can just blindly pass the arguments to the inherited method and know my class is ready for that? Uggg, being a self-taught developer sucks sometimes. I wish I had the CS background to make things like this a little easier. Plus I'm sure I would be exposed to more programming design methods. Right now the big hurdle is deciding how much heavy lifting should be done by an abstract class versus each individual subclass. That and deciding how to separate things out and make everything modular.
|
|
#
?
Dec 15, 2011 20:32
|
|
|
Dolemite posted:and fully expect the Bar object to work as expected in that its doThing method will always accept an integer for input and return an integer. Is that about right? In effect, Bar is locked into a contract defined by interface Foo and you can expect to only know you must pass an integer and you will get an integer back if you call doThing? Yes, in fact you could rewrite like this: code:
|
|
#
?
Dec 15, 2011 20:40
|
|
|
baquerd posted:Yes, in fact you could rewrite like this: Now let me understand this one: What you're doing here is creating a new object (newBarObject) and declaring it as type Foo (the interface). But, you are instantiating class Bar? Now, I can see how that is valid if Bar implements interface Foo and nothing else. In that case, they might as well be equivalent. But what happens if I call a method in newBarObject defined by class Bar but is not defined by interface Foo? If type Foo does not does not define the method I call, should it not fail? Now I know it doesn't fail since you're showing me this way of doing things. I'm interested in the theory behind that statement. I like that you're telling your program newBarObject IS a Foo type (and as such, expect the following constants and methods). That's pretty cool. 
|
|
#
?
Dec 15, 2011 21:24
|
|
|
Dolemite posted:Now let me understand this one: What you're doing here is creating a new object (newBarObject) and declaring it as type Foo (the interface). But, you are instantiating class Bar? I am creating a new object of type Bar and a variable that holds a reference to a Foo object that is pointed at the Bar object. The Bar object is of type Foo because it implements the Foo interface and so is a valid target for this reference. If Bar did not implement/extend Foo that code would not compile. quote:But what happens if I call a method in newBarObject defined by class Bar but is not defined by interface Foo? If type Foo does not does not define the method I call, should it not fail? code:
|
|
#
?
Dec 15, 2011 21:47
|
|
|
If you have an object of class Bar that inherits from class Foo, where Foo implements interface Baz, and Bar additionally implements interface Qux, the following is all valid:code:You may call any public method in Foo or Bar on A, but because the declared (formal) types of B, C and D do not have everything Bar has, you cannot call everything from Bar on those, because formally, those variables are not of type Bar. You can still call any public method from class Foo (or declared by interface Baz, since Foo implements that) on B, but not any of the methods of Qux or otherwise in Bar. On C, you can only call the methods declared in interface Baz, and on D you can only call the methods declared in interface Qux. An interface is a contract that allows your class to promise to adhere to some specification, and allows other code to accept any object that adheres to the specification, regardless of its actual implementation.
|
|
#
?
Dec 15, 2011 21:57
|
|
|
Can anyone recommend book(s) on small development team management? An opportunity may arise soon that sees two developers under me to help with excess work in terms of maintenance/new developments. I want to ensure I give them good, concise requirements and that their workload is managed well. Doesn't have to be a specific book if a more general book covers more ground and offers insight into common problems. I'm also interested in some books on data warehousing and business intelligence type stuff if anybody has any recommendations there too. Thanks
|
|
#
?
Dec 16, 2011 03:20
|
|
|
Dolemite posted:Now, I can see how that is valid if Bar implements interface Foo and nothing else. In that case, they might as well be equivalent. Almost. The idea is that many things can implement the Foo interface, and that the code does care not *which* one.
|
|
#
?
Dec 16, 2011 05:06
|
|
|
tef posted:the code does care not *which* one. And this is where I start not understanding Java. If we're supposed to not care about which type implements an interface, why is type dispatch so prevalent in the language? The instanceof operator, method overloading, etc.
|
|
#
?
Dec 16, 2011 06:47
|
|
|
Suspicious Dish posted:The instanceof operator, method overloading, etc.
|
|
#
?
Dec 16, 2011 07:07
|
|
|
Orzo posted:Both are bad practice, if that helps explain anything. That's not quite the question I asked, but in the interest of preserving my sanity, I'll take it. Suspicious Dish fucked around with this message at 07:11 on Dec 16, 2011 |
|
#
?
Dec 16, 2011 07:09
|
|
|
|
| # ? May 15, 2024 01:26 |
|
|
Suspicious Dish posted:And this is where I start not understanding Java. If we're supposed to not care about which type implements an interface, why is type dispatch so prevalent in the language? The instanceof operator, method overloading, etc. almost. sometimes you care, sometimes you don't. interfaces allow you to care about a subset of an objects features. it allows you to hide details from other bits of the code. interfaces provide a looser coupling than concrete type checks. object orientation is not a magic wand of structuring that makes clean code. good abstraction is hard. edit: interfaces turn out to be useful because of the inheritance model in java. if your object satisfies more than one 'type' of object, you must use interfaces to mark this.
|
|
#
?
Dec 16, 2011 07:23
|
|