Hi,
I'm not sure if this is the right group to ask. I am developing a
small image library and I don't know how to hide the actual path to
the image. So I go to the stock photo library websites to see how they
hide their images. This is what I see from gettyimages.com
<img src="http://cache2.asset-cache.net/xc/200186170-001.jpg?
v=1&c=NewsMaker&k=2&d=1EF4EE1EFB3A2CD3 E55FD7668143826B10621193DB58D674"
id="ctl12_ctlComp_imgThumb" class="thumbHeight">
Can someone please explain why there are parameters after the ".jpg",
which is not an executable file? I've got the link by right-click and
view image properties. However, if I just copy the link, and paste
into a new window, I won't see the image.
Any one knows what technique is this?
Thank you.
DP. 21  1537 
..oO(DP)
>I'm not sure if this is the right group to ask. I am developing a
small image library and I don't know how to hide the actual path to
the image. So I go to the stock photo library websites to see how they
hide their images. This is what I see from gettyimages.com
<img src="http://cache2.asset-cache.net/xc/200186170-001.jpg?
v=1&c=NewsMaker&k=2&d=1EF4EE1EFB3A2CD 3E55FD7668143826B10621193DB58D674"
id="ctl12_ctlComp_imgThumb" class="thumbHeight">
Can someone please explain why there are parameters after the ".jpg",
which is not an executable file? I've got the link by right-click and
view image properties. However, if I just copy the link, and paste
into a new window, I won't see the image.
Simple copy & paste won't work, since the link contains character
references (&), which are required for HTML. Try this one to get the
image: http://cache2.asset-cache.net/xc/200...621193DB58D674
>Any one knows what technique is this?
Just because you see a .jpg in the URL doesn't necessarily mean it is an
image. It can be anything else, in this case it could be a script that
returns an image based on the passed parameters.
Remember: a URL is just a string, nothing more. Things like "directory"
or "file extension" don't have a real meaning there. It's completely up
to server to decide what to do with something like ".jpg" at the end.
Micha
On 20 May, 23:47, DP <ldpha...@gmail.comwrote:
Hi,
I'm not sure if this is the right group to ask. I am developing a
small image library and I don't know how to hide the actual path to
the image. So I go to the stock photo library websites to see how they
hide their images. This is what I see from gettyimages.com
I'm not sure what you're after doing here. Hiding the path to an image
is not the same thing as hiding an image. If you hide an image, no one
can see it. If you allow someone to see it (on their browser), they
already have the image on their machine, in which case there is no
point in hiding the "path". I sometimes store images in a database
table, so there is no "path" as such.
If you want people to be able to see your images on their browser but
not to be able to keep a copy of them, forget it. There was a long
discussion about this recently. The bottom line is that the only thing
you can do to stop folks having a useful copy on their machine is to
put a watermark on the pictures.
Thanks Michael & Captain. I know that Apache httpd.conf can be set to
execute any extension (I just know the fact). I just don't know that
they use what technique to return the image. I have a few assumptions,
but don't know which one is best:
1. the '.jpg' is an executable script, and it reads the image data
from original image file in file system, adds watermark, and outputs.
Or it can read data from watermarked image (watermarked image is
created from upload time). Then what happens if I need to display 50
images in one page? the script only processes one by one.
2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)
On May 20, 4:47 pm, DP <ldpha...@gmail.comwrote:
>
I'm not sure if this is the right group to ask. I am developing a
small image library and I don't know how to hide the actual path to
the image. So I go to the stock photo library websites to see how they
hide their images. This is what I see from gettyimages.com
<img src="http://cache2.asset-cache.net/xc/200186170-001.jpg?
v=1&c=NewsMaker&k=2&d=1EF4EE1EFB3A2CD3 E55FD7668143826B10621193DB58D674"
id="ctl12_ctlComp_imgThumb" class="thumbHeight">
Can someone please explain why there are parameters after the ".jpg",
which is not an executable file?
Who knows... Maybe the parameters are just for logging and have no
use in
the actual application. Maybe the server is configure to rewrite
URLs...
I just copy the link, and paste into a new window, I won't see the image.
Any one knows what technique is this?
There is no technique. Try replacing "&" with "&": http://cache2.asset-cache.net/xc/200...621193DB58D674
The file is perfectly visible...
Cheers,
NC
..oO(DP)
>Thanks Michael & Captain. I know that Apache httpd.conf can be set to
execute any extension (I just know the fact). I just don't know that
they use what technique to return the image. I have a few assumptions,
but don't know which one is best:
1. the '.jpg' is an executable script, and it reads the image data
from original image file in file system, adds watermark, and outputs.
Or it can read data from watermarked image (watermarked image is
created from upload time). Then what happens if I need to display 50
images in one page? the script only processes one by one.
Each image request is independent from each other and will start another
instance of the script on the server. In theory 50 requests would invoke
the same script 50 times, but in practice this won't happen because of
some default limits each web server has. Usually at most 2 or 4 requests
from the same client to the same host are answered in parallel, all
others are delayed. The same happens with static files as well.
>2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)
The real issue will be the same as with #1: You have to call a script
for each image. That's the main impact to the overall site performance.
Whether the images are stored on disk or in a DB is more a question of
personal preference, although DB storage may slow things down even more
in such a case (50 script calls, 50 DB connections, 50 data transfers
from the DB to the script).
Micha
DP escribió:
1. the '.jpg' is an executable script
Actually, you have no way to find out where the URL points to. With
modules like Apache's mod_rewrite you can make http://example.com/foo/bar.jpg?a=1&b=1 point to http://example.com/scripts/do-fancy-stuff.php?x=2 and it'll be
completely invisible to site visitors.
Then what happens if I need to display 50 images in one page? the script only processes one by one.
That's true even with regular JPEG files: one file, one picture. God
bless caching, queueing and multitasking ;-)
2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)
Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--
Michael Fesser wrote:
.oO(DP)
>Thanks Michael & Captain. I know that Apache httpd.conf can be set to
execute any extension (I just know the fact). I just don't know that
they use what technique to return the image. I have a few assumptions,
but don't know which one is best:
1. the '.jpg' is an executable script, and it reads the image data
from original image file in file system, adds watermark, and outputs.
Or it can read data from watermarked image (watermarked image is
created from upload time). Then what happens if I need to display 50
images in one page? the script only processes one by one.
Each image request is independent from each other and will start another
instance of the script on the server. In theory 50 requests would invoke
the same script 50 times, but in practice this won't happen because of
some default limits each web server has. Usually at most 2 or 4 requests
from the same client to the same host are answered in parallel, all
others are delayed. The same happens with static files as well.
>2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)
The real issue will be the same as with #1: You have to call a script
for each image. That's the main impact to the overall site performance.
Whether the images are stored on disk or in a DB is more a question of
personal preference, although DB storage may slow things down even more
in such a case (50 script calls, 50 DB connections, 50 data transfers
from the DB to the script).
Micha
If you have a large number of images, a database is often faster than
the file system. Databases can easily handle 100K images; file systems
not so much.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Álvaro G. Vicario wrote:
DP escribió:
>1. the '.jpg' is an executable script
Actually, you have no way to find out where the URL points to. With
modules like Apache's mod_rewrite you can make
http://example.com/foo/bar.jpg?a=1&b=1 point to
http://example.com/scripts/do-fancy-stuff.php?x=2 and it'll be
completely invisible to site visitors.
>Then what happens if I need to display 50 images in one page? the
script only processes one by one.
That's true even with regular JPEG files: one file, one picture. God
bless caching, queueing and multitasking ;-)
>2. Images (and maybe watermarked images & thumbnails) are stored in
database. The script just returns data. I don't like this approach
because if I have hundreds of thousands of images, database is
probably not a good choice (from some discussions about storing images
in db vs. file system)
Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle escribió:
If you have a large number of images, a database is often faster than
the file system. Databases can easily handle 100K images; file systems
not so much.
If you mean "in the same directory", you're absolutely right.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--
On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
>Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.
It's a little rough on the incremental backups, though... (:
--
72. If all the heroes are standing together around a strange device and begin
to taunt me, I will pull out a conventional weapon instead of using my
unstoppable superweapon on them.
--Peter Anspach's list of things to do as an Evil Overlord
Álvaro G. Vicario wrote:
Jerry Stuckle escribió:
>If you have a large number of images, a database is often faster than
the file system. Databases can easily handle 100K images; file
systems not so much.
If you mean "in the same directory", you're absolutely right.
But putting them in different directories means having to plan for those
directories in your code - adding more programming overhead (and places
to go wrong). Additionally, if you don't "guess" right the first time,
you then need to go back and redo that code to get additional
directories. Or you have lots of directories with just 1 or 2 files in
each one.
I've been storing binary data in SQL databases since the mid 80's, when
we stored documents on a DB2 mainframe. It works great.
Other advantages - backups are easier - just backup the database. And
if you use a database/engine with referential integrity, you don't have
to worry about images being deleted from the file system and still being
pointed to in the database.
Additionally, you can have things like the image size stored in the
database with the image, so you don't have to go looking for it later.
You can even have a caption for it. And it's all one retrieval - not a
retrieval plus a file system call.
Databases are made for handling data. It doesn't matter if that data is
text or binary; it does both quite well.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Peter H. Coffin wrote:
On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
>Álvaro G. Vicario wrote:
>>Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle wrote:
Peter H. Coffin wrote:
>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
>>Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course
that's a good old discussion. I particularly find no benefits in it
(you can't do searches like "WHERE category_id=20 AND picture
PORTRAITS A 'black cat'") and it add an annoying overhead in all
related tasks.
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a
database can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
A database *is* files, Jerry.
On Sat, 24 May 2008 10:34:10 +0200, The Natural Philosopher <a@b.cwrote:
Jerry Stuckle wrote:
>Peter H. Coffin wrote:
>>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course
that's a good old discussion. I particularly find no benefits in it
(you can't do searches like "WHERE category_id=20 AND picture
PORTRAITS A 'black cat'") and it add an annoying overhead in all
related tasks.
>
>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a
database can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
A database *is* files, Jerry.
.... but backing up the files of a database instead of using proper
mechanisms is asking for corruption. It's not the physical presence on a
hard drive that's the problem, it's having to apply 2 different processes.
As a bonus, keeping a database in sync in another location is far easier
(with more mature tools) then syncing files. (Allthough I could not
imagine life without rsync)
--
Rik Wasmus
....spamrun finished
..oO(The Natural Philosopher)
>Jerry Stuckle wrote:
>Peter H. Coffin wrote:
>>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course
that's a good old discussion. I particularly find no benefits in it
(you can't do searches like "WHERE category_id=20 AND picture
PORTRAITS A 'black cat'") and it add an annoying overhead in all
related tasks.
>
>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a
database can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
A database *is* files, Jerry.
Not necessarily. You can keep entire databases in memory (can't get any
faster) or even store multiple databases in a single file, which is what
InnoDB does for example. But for the user and often even for the admin
it's of no interest how the database actually stores the data. Messing
with that and directly accessing the container files in case of a disk-
based DB calls for trouble. Real trouble!
Micha
Rik Wasmus wrote:
On Sat, 24 May 2008 10:34:10 +0200, The Natural Philosopher <a@b.cwrote:
>Jerry Stuckle wrote:
>>Peter H. Coffin wrote:
On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
>Some guys adore storing binary data in databases but of course
>that's a good old discussion. I particularly find no benefits in
>it (you can't do searches like "WHERE category_id=20 AND picture
>PORTRAITS A 'black cat'") and it add an annoying overhead in all
>related tasks.
>>
>>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a
database can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have
to back up files and database. Just the database.
A database *is* files, Jerry.
... but backing up the files of a database instead of using proper
mechanisms is asking for corruption. It's not the physical presence on a
hard drive that's the problem, it's having to apply 2 different
processes. As a bonus, keeping a database in sync in another location is
far easier (with more mature tools) then syncing files. (Allthough I
could not imagine life without rsync)
So in effect, C-ISAM apart, backing up a database is actually HARDER
than backing up ordinary files?
Michael Fesser wrote:
.oO(The Natural Philosopher)
>Jerry Stuckle wrote:
>>Peter H. Coffin wrote:
On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
>Some guys adore storing binary data in databases but of course
>that's a good old discussion. I particularly find no benefits in it
>(you can't do searches like "WHERE category_id=20 AND picture
>PORTRAITS A 'black cat'") and it add an annoying overhead in all
>related tasks.
>>
>>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a
database can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
A database *is* files, Jerry.
Not necessarily. You can keep entire databases in memory (can't get any
faster)
Cant get any worse if the system crashes..
or even store multiple databases in a single file, which is what
InnoDB does for example.
It's still a file ;-)
But for the user and often even for the admin
it's of no interest how the database actually stores the data. Messing
with that and directly accessing the container files in case of a disk-
based DB calls for trouble. Real trouble!
Actually I have backed up copied and restored C-ISAM files for years
with no problems.
I've even done it without shutting down the copied-from database engine.
On the basis that if I got a bunch of junk when using the copy, I'd do
it properly the longer away round..but in fact it worked.
Micha
On Sat, 24 May 2008 11:22:54 +0200, The Natural Philosopher <a@b.cwrote:
Rik Wasmus wrote:
>On Sat, 24 May 2008 10:34:10 +0200, The Natural Philosopher <a@b.c>
wrote:
>>Jerry Stuckle wrote:
Peter H. Coffin wrote:
On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
>Álvaro G. Vicario wrote:
>>Some guys adore storing binary data in databases but of course
>>that's a good old discussion. I particularly find no benefits in
>>it (you can't do searches like "WHERE category_id=20 AND picture
>>PORTRAITS A 'black cat'") and it add an annoying overhead in all
>>related tasks.
>>>
>>>
>The ability to search is not the only reason to store things in
>databases. And if you have hundreds of thousands of images, a
>database can be more efficient.
>
It's a little rough on the incremental backups, though... (:
>
Only the first time. But it makes backups easier - you don't have
to back up files and database. Just the database.
A database *is* files, Jerry.
... but backing up the files of a database instead of using proper
mechanisms is asking for corruption. It's not the physical presence on
a hard drive that's the problem, it's having to apply 2 different
processes. As a bonus, keeping a database in sync in another location
is far easier (with more mature tools) then syncing files. (Allthough I
could not imagine life without rsync)
So in effect, C-ISAM apart, backing up a database is actually HARDER
than backing up ordinary files?
Certainly not. Either point to another database server and say 'just keep
a most recent copy of that server', or use the tool (mysql would be
mysqldump) for the job. Easier to do it right then files, with a lot less
duplicate overhead in most cases. Mind the 'do it right', of course just
downloading / copying files to another point is toddler-easy, but on its
own that's not an ideal backup method. I had more troubles setting up
rsync then a slave mysql database.
--
Rik Wasmus
....spamrun finished
The Natural Philosopher wrote:
Jerry Stuckle wrote:
>Peter H. Coffin wrote:
>>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course
that's a good old discussion. I particularly find no benefits in it
(you can't do searches like "WHERE category_id=20 AND picture
PORTRAITS A 'black cat'") and it add an annoying overhead in all
related tasks.
>
>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a
database can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
A database *is* files, Jerry.
Not necessarily. It depends on the implementation.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Fri, 23 May 2008 12:10:15 -0400, Jerry Stuckle wrote:
Peter H. Coffin wrote:
>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
>>Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
Which DBMS do incremental backups well? I'm mostly familiar with MySQL
and DB2 and both of those are pretty much "shut things down, back up the
whole thing" every single time, while using filesystem storage for
100000 images would mean backing up 99940 only once, then the handful of
new or changed ones every increment. And it takes quite a different
amount of time on my ancient tape drives to back up 10GB instead of
2-3MB.
--
Better to teach a man to fish than to give him a fish. And if he can't
be bothered to learn to fish and starves to death, that's a good enough
outcome for me.
-- Steve VanDevender
Peter H. Coffin wrote:
On Fri, 23 May 2008 12:10:15 -0400, Jerry Stuckle wrote:
>Peter H. Coffin wrote:
>>On Fri, 23 May 2008 07:40:37 -0400, Jerry Stuckle wrote:
Álvaro G. Vicario wrote:
Some guys adore storing binary data in databases but of course that's a
good old discussion. I particularly find no benefits in it (you can't do
searches like "WHERE category_id=20 AND picture PORTRAITS A 'black
cat'") and it add an annoying overhead in all related tasks.
>
>
The ability to search is not the only reason to store things in
databases. And if you have hundreds of thousands of images, a database
can be more efficient.
It's a little rough on the incremental backups, though... (:
Only the first time. But it makes backups easier - you don't have to
back up files and database. Just the database.
Which DBMS do incremental backups well? I'm mostly familiar with MySQL
and DB2 and both of those are pretty much "shut things down, back up the
whole thing" every single time, while using filesystem storage for
100000 images would mean backing up 99940 only once, then the handful of
new or changed ones every increment. And it takes quite a different
amount of time on my ancient tape drives to back up 10GB instead of
2-3MB.
DB2 actually will do incremental backups based on the binary logs.
MySQL doesn't do that yet - but you can emulate it with a slave.
You probably could do an incremental backup with MySQL based on the
binary logs, but I don't know how hard it would be.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jasonshohet |
last post by:
I read recently that: "if a before-image was made before an
interruption in database processing, you use the before-image dump &
simply begin processing again from just before the last...
|
by: Sean Berry |
last post by:
I have an online store that a customer needs customized by having notes for
each product. I have added a javascript function that sends a session id,
unique product id and some user-defined notes...
|
by: Mainlander |
last post by:
An ISP I belong to uses Majordomo for their mailing list system. I'd like
to encourage them to move to a system that uses a database, preferably
psql which they already run on their server....
|
by: Fernando Cacciola |
last post by:
Hi, I'm terribly new at C# (come from C++ land).
I'm making some benchmarks to see the effect of different coding styles, and
I run across a situation that strikes me as pretty odd.
For my image...
|
by: archana |
last post by:
Hi all,
I am using timer to do some functionality on user specified time.
I am using system.timers.timer class and its timer to do this
functionality. What i am doing is i set autoreset to...
|
by: Enrique Cruiz |
last post by:
Hello all,
I am currently implementing a fairly simple algorithm. It scans a
grayscale image, and computes a pixel's new value as a function of its
original value. Two passes are made, first...
|
by: Dave.Sun.Moon |
last post by:
Dear all,
I am not a professional programmer. In stead, I am using C++ mostly
for my research work. My knowledge of C++ is only good enough for my
computation. I really don't use the advanced...
|
by: tavares |
last post by:
(Our apologies for cross-posting.
We appreciate if you kindly distribute this information by your co-
workers and colleagues.)
...
|
by: Christian Schlemmer |
last post by:
Hi,
in a webapplication, after a submit a page is called which is processing
images uploaded by the user. currently after submit a status bar will be
visible (the page for the image processing...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
